For what it's worth, I am in agreement with Derick... Consistency is important..
Besides... A rose is still a rose, even if it's called sweet_smelling_flower ;) >OK, I will admit the '_' is then OK, but I rather do not use >it in this case, since I would like to use that for a more >session oriented >functions. I'm >As an example: >$sess_v1 = snmp_session(1, "localhost:161", "public"); >$sess_v3 = snmp_session(3, "otherhost:161", "username", "seclevel", > "auth_protocol", "auth_passphrase", > "priv_protocol", "priv_passphrase"); > >$vara = snmp_get($sess_v1, "sysUpTime.0"); >$varb = snmp_get($sess_v3, "sysUpTime.0"); > > >> Abbreviations should not be used when they greatly decrease the >> readability of the function name itself. >> >> Good: >> 'mcrypt_enc_self_test' >> 'mysql_list_fields' >> >> ... >> >> [2] If they are part of a "parent set" of functions, that >parent should >> be included in the user function name, and should be >clearly related >> to the parent program or function family. This should be >in the form >> of parent_*. >> >> A family of 'foo' functions, for example: >> Good: >> 'foo_select_bar' >> 'foo_insert_baz' >> 'foo_delete_baz' >> >> ... >> >> [5] Variable names should be in lowercase. Use underscores >to separate >> between words. >> >> >> more of all, it's common practise with all extensions. If you find >> some which do not adhere to this standard, then there was taken into >> account a BC problem. > >For that alias could have been made to assist people in a >migration phase. > >> This is not the case with new functions, like you added, >> and thus they should stick to the guide lines. >> > >I do not see any problem with the usage of 'v3'. > >>> >>>> As those >>>> are new functions I propose to change them to the following, to be >>>> more >>>> consistent with all other functions: >>>> >>>> snmpv3get -> snmp3_get >>>> snmpv3walk -> snmp3_walk >>>> snmpv3realwalk -> snmp3_real_walk (or snmp3_walk_oid) >>>> snmpv3set -> snmp3_get >>> >>> I have mentioned this some time ago already on the list. (See >>> archive) I believe it is way easier for people to recognise the >>> SNMPv3 version by people with the current naming. On top of that I >>> can understand all of your concerns, but it is my opinion >we have to >>> think what is the easiest for the users/programmers of PHP. >> >> the proposed names are much more readable, and they follow the oci8_ >> convention of only using the verison number, the 'v' in your names >> don't add anything useful. > >I think it will create confusion when I am done with the new >more session oriented approach. That I believe is neither >something needed if can be avoided. > >> >>> IMHO, the current naming refers quite clearly to SNMP version 3 or >>> SNMPv3. Many people know this version of the protocol as SNMPv3. I >>> beleive that the original functions did neither have an '_' >>> character. Why is that required suddenly?? >> >> Backward compatibility for those. Maybe you noticed that we >added some >> aliases to other extensions because of this, but the snmp extension >> was left alone in that. AFAIK, changing or aliasing names is on the >> PHP 5 todo. > >So, are you saying you should have renamed them all and >keeping an alias for the BC?? > >> >>> (This states more or less the same opinion as expressed last time) >>> >>> I also would like to mention that I am looking into the usage of an >>> SNMP-session creation and then use a single variable to provide all >>> SNMP-session info in a single variable for the 'data retrieval' >>> functions. Therefore, I would like to reserve the use of the >>> underscore and then without a version number. >> >> As long as you don't break BC it's fine with me. > >That is why I would like to keep it as is and how I propose >it. It would be less confusing for PHP-coders. But I know this >is a personal opinion. > >> >>> >>>> also, there is no need to introduce an alias for a newly created >>>> function so I guess we just should drop it. >>> >>> I have created a similar set of functions as exist for SNMPv1. That >>> includes the alias. That makes it easier for existing scripts to be >>> updated with the new security featres of SNMPv3. >> >> We only add aliases if it is absolutely necesary, which is >really not >> the case here. >> >>>> I'd like to make those proposed changes ASAP as they are >also added >>>> in the PHP_4_3 branch which gets closer to release everyday. >>> >>> Personally, I do not prefer and like the name change suggested. >>> >>> The name snmp3_ looks to me quite weird, since the world knows this >>> as SNMPv3. Therefore, the use of snmpv3 is preferred. >> >> yeah, and oci is really called oraclecinterface, so let's fix that >> too! > >You also could have named it with the 'o' prefix. >Do I have to laugh here?? > >> >>> I am even tending to give it a -1, but there is not >technical reason. >>> But there is neither a good technical reason in favour of the name >>> change. >> >> It has little to do with a techincal reason, but more of a logical >> one. As all functions in PHP extensions follow the same >nameing style >> this makes it easier for users to work with it; that's the main >> concern here, and that's why I'd like to change the names. > >I am now really curious as what is seen as easier to work >with?? In to many cases I have seen that 'easier' is dictated >by the developers of the tools. In this case the C-coders not >the PHP coder/developer. > >Cheers, > >Harrie >------------------------------------------------------------------ >Author of MOD-SNMP, enabling SNMP management of Apache HTTP server > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
