Hi all, On Wed, Jul 30, 2014 at 9:35 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> > - Consistent naming >> - Consistent parameter order >> - Graceful function/class/interface deprecation >> (We know what we should do for these, right?) >> > > I'm not sure if this was meant sincerely, or slightly tongue-in-cheek, but > no, we definitely don't. It comes up on the list every few months (I've > only been subscribed a short time, but this is at least the 4th time I've > seen), and the general conclusion is there isn't an easy answer, and that > adding more namespaces doesn't particularly help. > One of the discussion is mine, I suppose. This is because cleaning up API cannot be done w/o breaking some except simple aliasing. Even if there are issues in API, there isn't a consensus for feasible resolution yet. Namespace is good resolution obviously. It accomplishes compatibility and consistency at the same time even when parameters or class/interface definitions are changed. > Making small changes, such as extra function aliases, or identical > versions of existing functions with switched parameter order, just adds to > the overall confusion and list of special cases that users have to carry > around when reading and writing code. > We make small changes in versions always. API changes are small changes also. The difference is BC. Since API change breaks APP, it wasn't changed for a long time. Use of alias was proposed several times, but it wasn't optimum and couldn't reach to consensus. With namespace, user may choose. We don't force users to *new* or *old* way. There is no BC issue. It's users' choice. If we care about confusion, we may change API only with major release to minimize it. That leaves the option of making larger changes, to design a clear new API, > deliberately *minimising* the similarity to existing functions so it's > clear when you're using what. The popular option for that is migrating > chunks of functionality to OOP (as with DateTime), and to pseudo-OOP > "scalar methods" (of which there are a couple of prototypes) - not to turn > PHP into a pure OOP language, just to give us a chance to design a more > consistent library of functions. Unless we rewrite everything completely, it wouldn't be accomplished. This has been said for years (more than a decade AFAIK) and didn't happen. Therefore, new API is not feasible by history. Even when we rewrite everything, are we going to remove old API? It's BC, so I guess not. Most legacy/obscure API will remain as it is now and usable by default. New API doesn't help some time. For example, SessionHandlerInterface has some variations and has issue for adding to it. Instead having many SessionHandlerXXXInterface, simply selecting proper namespace is simpler/cleaner. Having new Session2 class only for simpler interface name does not make sense. Since we don't have new major release often, it would be good for users cleaning up API with every new major versions. Otherwise, legacy/obscure APIs will remain 10 years or even 20 years later for sure. (In fact, we have legacy APIs almost 20 years that are used commonly) Use of namespace guarantees new PHP has consistent/modern API. This will neutralize/negate all cons, IMO. cons are - New php.ini (default namesapce setting) - Legacy API can be used and remains (this is pros also) - Confusing to current users by having versions of API. (confusing API is confusing for both new and current users, too) If there are more cons, please add them. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
