Hi Ardids, On Fri, Mar 6, 2015 at 8:22 AM, Arvids Godjuks <arvids.godj...@gmail.com> wrote:
> Why not take advantage of namespaces and do the new API, building it up > version by version (sure it can't be done in one go), so probably the > extensions gonna follow too. > That allows you to use as OO interface, so do the functions. Well, yes, it > will be under a namespace, but at least new projects can be started that > way. And old code will be easy enough to port, it's mostly a question of > refactoring tools. > This just does not work for people oppose to have new names for consistency. This proposal do not break scripts, almost. Therefore, namespace is not mandatory. We should have namespace for internal functions. I agree this part. Even if we have namespace that could work for internal functions, we still need standard confirming names. I propose PHP and IEEE as procedural function name standards. > > Aliasing is a stop-gap measure, isn't it? API's tend to get redesigned and > PHP's is due to a major makeover. So, why not embrace it? No one's forcing > to retire the old one any time soo, and I belive people understand it will > be a very long time before it is phased out, if ever (well, I think in like > 20 years probably is doable). And if done right, it may be done in a way > that if you don't need it, you can leave out the old API on compile stage - > not sure if doable thought. > It's not about gap or having new API, but having consistent name. Most procedural APIs except misordered parameter do not need new API. They only needs consistent names. Please suggest better/right way. Having namespace is not alternative for having consistent names. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
