Re: Contribution for PECL

From: Date: Sat, 28 Dec 2002 13:41:37 +0000
Subject: Re: Contribution for PECL
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-11874@lists.php.net to get a copy of this message
> Wow, I don't understand several things in this thread. > > 1) Why does he have to find some meaningless prefix? Is this a new rule > for all packages? I understand that when we have two packages that > compete we must find a solution to the naming clashes this might create. > But I say its tough luck for the package that comes second. Because we > never know when it does or if it will ever come. > Well, the idea of a good naming convention is not saying tough luck to either package. In pear there is the concept of top-level package names and then subsequent sub-classes. Even library authors (in the general C sense) will most often prefix the function calls with something relatively unique, I don't think it should be different here. tmpl_* is too "common" for me, and I don't think that in general it should be claimed by a PHP extension (I would be giving this advice were it not to be accepted as a PECL library, but now that is, well, my opinion is all the more relevant ;-). I liked the idea of max, etc. simply because then you have a unique naming convention, something that most likely will not be claimed in people's code as a standard CS term. > 2) He is contributing something to PECL and not to the core of PHP. > While Smarty is very cool and fast I can see a lot of reasons not to use > it. But that is not the point. Its Ok to ask about the hows and whys of > the package, but not in this "there is this package, so I guess you can > go home" tone. > yeah, for my part we took the conversation off-list, I made it clear (in that conversation) that I didn't mean to stop/discourage him (not that I could). Certainly, everyone is entitled to their opinion on this issue, no matter whether they are wrong or not. ;-) I was just interested in his reasoning... -Sterling

« previous php.pear.dev (#11874) next »