Re: New SNMP function names

On Thu, 5 Dec 2002, Harrie Hazewinkel wrote: > > [1] Function names for user-level functions should be enclosed with in > > the PHP_FUNCTION() macro. They should be in lowercase, with words > > underscore delimited, with care taken to minimize the letter count. > > 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. > > 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"); Why didn't you introduce this right away then, if this would be the recommend way then we don't even need the snmpv3* functions. > > 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. but adding an alias, because there was an alias for another function just doesn't compute to me. > > > 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'. I do. > >> 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?? Actually, yes. But there are no aliases needed for the new functions of course. > >> 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. argh, how can hardly readable functoin names be _more_ confusing then nicely readable function names? > >> 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. But not thinking of users is kinda weird, and I like an example of your statement that 'easier' is dedicated by the developers as I can't think of one. Derick -- ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------