Hi Rowan, On Mon, Aug 18, 2014 at 12:28 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 15/08/2014 01:46, Yasuo Ohgaki wrote: > > On Wed, Jul 30, 2014 at 9:35 PM, Rowan Collins <rowan.coll...@gmail.com >> <mailto:rowan.coll...@gmail.com>> wrote: >> >> 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. >> > > When we talk about compatibility of an API, we are normally talking about > how an existing piece of code connects to another program, library, or > service. But when you're talking about the core functions of a language, > the consumer of that API is the programmer themselves, when writing new > code and reading old. > > One of the problems which we would like to fix is that pogrammers have to > stop and think "Does array_map take the array first, or the callback?" > Because there isn't a good rule of thumb, each function has to be > remembered or looked up individually. > > I have previously been tempted by the thought of adding a new set of > functions with a clearer design, but on reflection, I realise that you just > end up making the problem worse: now the programmer has to ask themselves > extra questions, like "Does PHP\Array\map take the arguments in the same > order as array_map? Which am I supposed to be using in this project?" > > Add in namespace aliasing, or a magic ini setting that hides the old > functions and puts the new ones in their place, and reading code becomes > equally confusing: "When it says array_map here, is that the classic PHP > function, or a new version aliased in? What differences are there between > the two?" > > I'm not intended to divide global name space into parts. Current(most updated API) namespace and legacy(older API) namespace would be enough. Namespace may have version. (5, 7, and so on) Therefore, user would not confuse like you describe. For example, when a library major version incremented, API may differ. Users may use new or old API selectively. I would like to have a choice to use cleaner API or older API like library API. > If we divide namespace into pieces and change API frequently (i.e with minor or bugfix version up), then it's confusing for sure. I'll against such usage. > With namespace, user may choose. We don't force users to *new* or *old* >> way. >> > > Individual users can't choose, because they will be contributing to > projects - be they open source or commercial - with coding standards based > on the platforms supported, the size of the existing code base, and the > prejudices of project leaders. And the current trend in open source > projects is towards more co-operation and standardisation (e.g. PHP-FIG), > so adding a new thing to disagree on would be unfortunate to say the least. > Libraries/Projects may choose appropriate namespace (e.g. 5, 7, and so on) like choosing specific library version mostly. Issue would be if new PHP allows to import namespace into "\" (root). Older PHP would complain if default namespace is specified in scripts. php > use PHP\5 as \; Parse error: syntax error, unexpected '\' (T_NS_SEPARATOR), expecting identifier (T_STRING) in php shell code on line 1 and PHP does not have C like macro. I have to come up with solution for this. > If we care about confusion, we may change API only with major release to >> minimize it. >> > > I can't imagine an API change of that sort being even considered outside > of a major release. > > > > 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. >> > > So what is it you suggest instead? A series of namespaces with slightly > different versions of all the functions, introduced over time, and every > file having to declare at the top "use PHP7;", "use PHP8;" etc? > Yes. Something like this. Since 'PHP' is reserved namespace name, "PHP\5", "PHP\7", "PHP\8" perhaps. > Use of namespace guarantees new PHP has consistent/modern API. This will >> neutralize/negate all cons, IMO. >> > > I'm really not sure what problems adding one or more namspaces solves. > > If you just arrange the existing functions into namespaces with better > naming conventions, then it's just the same as any other set of aliases; > it's clear which are the "old" names and which the "new", but that's about > the only benefit. If you make the functions superficially similar, but with > minor changes like argument order or error-handling, then the cost of > adoption is even higher. > I like alias also and have proposed use of aliases before. It may be good idea to use aliases as much as possible for simple name changes. Whole point of namespace use is to remove small inconsistency and/or improper names (e.g. SessionHandlerInterface) with major release so that small inconsistency would not be added up and have cleaner API for new major versions. Coding standards are unlikely to accept a mixing of old and new styles in > one project, and bulk conversion of existing code is only possible if you > drop support for older PHP versions. So in order to adopt the new functions > at all, programmers would have to learn both APIs, and remember the > differences between them when switching projects. More likely, they would > simply carry on using the old functions even in new projects, because the > benefit of a slightly better parameter order here and there wouldn't be > worth the cost of learning it. > Besides function/method name aliasing, changes in namespace would be small enough to adopt/learn. New major release has long list of changes always. Adding a few would not make much difference. IMHO. > > Further, if a magic ini setting could change which set of functions is in > scope, then distributing code libraries becomes a nightmare. Some libraries > include code to work around the ability to overwrite strlen() with > mb_strlen(), meaning there's no safe function for getting the number of > bytes in a string, and this would be much more far-reaching. > PHP allows overriding strlen() by mb_strlen(), etc, with namespace already. (Unless there is a function byte_len(), this would not be practical as you mentioned. If "PHP" namespace is used, programmers may write "PHP\5\strlen($str);", though.) > The reason I think major changes are less likely to fail than minor ones > is that you can avoid the confusion of which version is which, and offer a > much stronger benefit to adopting the new style. For instance, "scalar > methods" are both very distinct from existing code, and naturally give > actions a "subject", e.g. $a = [1,3,2]; $a->map($callback); They have the > inherent attraction (for some people) of giving code an OO flavour. > I like the idea and I'm +1 for this. There is such RFC also. https://wiki.php.net/rfc/autoboxing BTW, I also preferred to keep procedural API. Everything does not have to be an object and I would like to have choice (e.g MySQLi, session save handler) > > But even then, there is a possibility of a schism in the language, with > some projects opting to stick to compatible, familiar, functions and others > moving to the modern-looking, redesigned, API. And that's definitely not > something I want to see. > Using namespace for cleaning current API is just an idea. I'll write a FRC when I came up with concrete idea and hope you like it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
