Re: [PHP-DEV] PHP namespace?
On 23/08/2014 04:39, Yasuo Ohgaki wrote: Hi Rowan, On Mon, Aug 18, 2014 at 12:28 AM, Rowan Collins rowan.coll...@gmail.com mailto:rowan.coll...@gmail.com wrote: On 15/08/2014 01:46, Yasuo Ohgaki wrote: 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. It doesn't matter if you have 1, 5, or zero namespaces, the problem is having to learn more than one version of the same function. If PHP\5\array_map and PHP\7\array_map took different arguments, the language would be harder to learn, not easier. 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. I'm not sure what dividing the namespace into pieces has to do with frequent updates. My feeling is that if you're going to go with namespaces, you might as well actually use them to group functions, so rather than PHP\array_map (or PHP\7\array_map) it could be PHP\Array\map (or PHP\7\Array\map). 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. Yes, and users making use of and contributing to multiple projects will have to learn both versions. Thus the more subtle variations there are between the versions, the more they'll have to learn. You also didn't respond to my point that introducing the extra choice means one more barrier to smooth co-operation between projects. 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. This sounds like a recipe for massive confusion to me, for the reasons I've already tried to explain. 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. You can make the changes without introducing namespaces, so saying that the point of namespaces is to make changes makes no sense. I think what you're getting at is that namespaces allow PHP to contain *multiple versions of the same function or class*, which aren't simply aliases, but have different behaviour in some way. That
Re: [PHP-DEV] PHP namespace?
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
Re: [PHP-DEV] PHP namespace?
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? 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. 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? 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. 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. 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. 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. But even then, there is a possibility
Re: [PHP-DEV] PHP namespace?
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
Re: [PHP-DEV] PHP namespace?
Yasuo Ohgaki wrote (on 28/07/2014): - 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. 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. 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. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP namespace?
Hi Andrey, On Mon, Jul 28, 2014 at 4:42 PM, Andrey Andreev n...@devilix.net wrote: This would be a major BC break, that couldn't possibly happen in PHP 5.x and IMO is way too radical even for PHP 6/7. It wouldn't be major BC, but minor. Most compatible way is to allow namespace alias to \ (root) and simply override existing functions. There isn't BC with this. PHP allows it already when it is done one by one. If we would like to have clean \ (root) namespace optionally, it's matter of adding a setting. What make you think it a major BC? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] PHP namespace?
Hi Ferenc, On Mon, Jul 28, 2014 at 5:22 PM, Ferenc Kovacs tyr...@gmail.com wrote: namespaces has a bit clunky way of supporting constants: define always assumes global ns(and the const syntax only allows scalar values so it isn't always an option to use const). define() is problem because it's an exception. Possible solution might be make define()ed constants aware namespace and allow importing them to \ (root). Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] PHP namespace?
Hi,
On Mon, Jul 28, 2014 at 5:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion would be
nice
to have.
Currently, PHP module functions/classes/interfaces are using global(root)
namespace.
If it is changed to use its own namespace, user space APIs may be changed
flexible and user controlled manner. Thus, PHP may have
- Consistent naming
- Consistent parameter order
- Graceful function/class/interface deprecation
(We know what we should do for these, right?)
without much compatibility issues.
PHP namespace may be used to provide PHP(and 3rd party)
functions/classes/interfaces/constants.
PHP\Legacy (or whatever) may be used for legacy
functions/classes/interfaces/constants.
From PHP 5.6, userland function aliasing can be done with namespace.
Following code overrides existing function.
?php
use function \mb_strlen as strlen;
var_dump(strlen('日本語'));
?
Result:
int(3)
It's good to use prefered API, but it requires use for every function
APIs to be overridden.
Note: Classes/Interfaces may override by use one by one also.
With PHP and PHP\Legacy namespace, user may write:
?php
namespace PHP; // Use current PHP functions/classes/interfaces/constants
// Code uses current API
?
?php
namespace PHP;
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
For compatibility, default namespace setting would be nice to have.
- None for compiled default
- PHP for php.ini-*
Previous example codes became:
?php
// Code uses current API
?
?php
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
Issue would be codes that assume PHP functions/classes/interfaces/constants
are
defined in global(root) namespace. (e.g. \strlen()) This could be
workaround by allowing
use aliasing to global(root) namespace. (e.g. use PHP\Legacy as \;) In
this case,
current functions/classes/interfaces may stay in global(root) namespace.
(or use PHP as \;)
Programmers may shoot their own foot by this. This is the trade off of
flexibility.
Any thoughts and/or comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
This would be a major BC break, that couldn't possibly happen in PHP
5.x and IMO is way too radical even for PHP 6/7.
I generally hate to see statements like this is not the PHP way, but
that's exactly the case with your proposal - it _enforces_ a more
strict way of programming. One must absolutely not be required to use
namespaces for everything.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP namespace?
One must absolutely not be required to use namespaces for everything. +1 I fully share this statement as well. Please, do not force any user to use namespaces. PHP's never been namespace based, it added their support to 5.3. IMO, PHP should never be namespace based for its own syntax. Julien.P
Re: [PHP-DEV] PHP namespace?
On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion would be
nice
to have.
Currently, PHP module functions/classes/interfaces are using global(root)
namespace.
If it is changed to use its own namespace, user space APIs may be changed
flexible and user controlled manner. Thus, PHP may have
- Consistent naming
- Consistent parameter order
- Graceful function/class/interface deprecation
(We know what we should do for these, right?)
without much compatibility issues.
PHP namespace may be used to provide PHP(and 3rd party)
functions/classes/interfaces/constants.
PHP\Legacy (or whatever) may be used for legacy
functions/classes/interfaces/constants.
From PHP 5.6, userland function aliasing can be done with namespace.
Following code overrides existing function.
?php
use function \mb_strlen as strlen;
var_dump(strlen('日本語'));
?
Result:
int(3)
It's good to use prefered API, but it requires use for every function
APIs to be overridden.
Note: Classes/Interfaces may override by use one by one also.
With PHP and PHP\Legacy namespace, user may write:
?php
namespace PHP; // Use current PHP functions/classes/interfaces/constants
// Code uses current API
?
?php
namespace PHP;
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
For compatibility, default namespace setting would be nice to have.
- None for compiled default
- PHP for php.ini-*
Previous example codes became:
?php
// Code uses current API
?
?php
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
Issue would be codes that assume PHP functions/classes/interfaces/constants
are
defined in global(root) namespace. (e.g. \strlen()) This could be
workaround by allowing
use aliasing to global(root) namespace. (e.g. use PHP\Legacy as \;) In
this case,
current functions/classes/interfaces may stay in global(root) namespace.
(or use PHP as \;)
Programmers may shoot their own foot by this. This is the trade off of
flexibility.
Any thoughts and/or comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
hi,
I think it would make sense to announce that the php namespace is reserved
for internal use, but I don't think that we are ready for moving everything
under namespaces.
The way we currently implement namespaces can't support wildcard imports so
the migration for project would be pretty tedious, finding and replacing
every occurance of a global function/class or use-ing every function/class,
etc.
namespaces has a bit clunky way of supporting constants: define always
assumes global ns(and the const syntax only allows scalar values so it
isn't always an option to use const).
moving the functions to namespaces would be also a bit weird for me, as we
currently don't support function (and const) autoloading, so it would be a
mixed message about whether or not do we consider functions and constants
first-class citizens used together with the later introduced oop features.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP namespace?
On 28 July 2014 09:22, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion would
be
nice
to have.
Currently, PHP module functions/classes/interfaces are using global(root)
namespace.
If it is changed to use its own namespace, user space APIs may be changed
flexible and user controlled manner. Thus, PHP may have
- Consistent naming
- Consistent parameter order
- Graceful function/class/interface deprecation
(We know what we should do for these, right?)
without much compatibility issues.
PHP namespace may be used to provide PHP(and 3rd party)
functions/classes/interfaces/constants.
PHP\Legacy (or whatever) may be used for legacy
functions/classes/interfaces/constants.
From PHP 5.6, userland function aliasing can be done with namespace.
Following code overrides existing function.
?php
use function \mb_strlen as strlen;
var_dump(strlen('日本語'));
?
Result:
int(3)
It's good to use prefered API, but it requires use for every function
APIs to be overridden.
Note: Classes/Interfaces may override by use one by one also.
With PHP and PHP\Legacy namespace, user may write:
?php
namespace PHP; // Use current PHP functions/classes/interfaces/constants
// Code uses current API
?
?php
namespace PHP;
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
For compatibility, default namespace setting would be nice to have.
- None for compiled default
- PHP for php.ini-*
Previous example codes became:
?php
// Code uses current API
?
?php
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
Issue would be codes that assume PHP
functions/classes/interfaces/constants
are
defined in global(root) namespace. (e.g. \strlen()) This could be
workaround by allowing
use aliasing to global(root) namespace. (e.g. use PHP\Legacy as \;)
In
this case,
current functions/classes/interfaces may stay in global(root) namespace.
(or use PHP as \;)
Programmers may shoot their own foot by this. This is the trade off of
flexibility.
Any thoughts and/or comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
hi,
I think it would make sense to announce that the php namespace is reserved
for internal use, but I don't think that we are ready for moving everything
under namespaces.
For what it's worth, the manual already states that the php namespace is
reserved for us.[1]
The way we currently implement namespaces can't support wildcard imports so
the migration for project would be pretty tedious, finding and replacing
every occurance of a global function/class or use-ing every function/class,
etc.
namespaces has a bit clunky way of supporting constants: define always
assumes global ns(and the const syntax only allows scalar values so it
isn't always an option to use const).
moving the functions to namespaces would be also a bit weird for me, as we
currently don't support function (and const) autoloading, so it would be a
mixed message about whether or not do we consider functions and constants
first-class citizens used together with the later introduced oop features.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
[1] http://php.net/manual/en/language.namespaces.rationale.php
Re: [PHP-DEV] PHP namespace?
On Mon, Jul 28, 2014 at 10:49 AM, Peter Cowburn petercowb...@gmail.com
wrote:
On 28 July 2014 09:22, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion would
be
nice
to have.
Currently, PHP module functions/classes/interfaces are using
global(root)
namespace.
If it is changed to use its own namespace, user space APIs may be
changed
flexible and user controlled manner. Thus, PHP may have
- Consistent naming
- Consistent parameter order
- Graceful function/class/interface deprecation
(We know what we should do for these, right?)
without much compatibility issues.
PHP namespace may be used to provide PHP(and 3rd party)
functions/classes/interfaces/constants.
PHP\Legacy (or whatever) may be used for legacy
functions/classes/interfaces/constants.
From PHP 5.6, userland function aliasing can be done with namespace.
Following code overrides existing function.
?php
use function \mb_strlen as strlen;
var_dump(strlen('日本語'));
?
Result:
int(3)
It's good to use prefered API, but it requires use for every function
APIs to be overridden.
Note: Classes/Interfaces may override by use one by one also.
With PHP and PHP\Legacy namespace, user may write:
?php
namespace PHP; // Use current PHP functions/classes/interfaces/constants
// Code uses current API
?
?php
namespace PHP;
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
For compatibility, default namespace setting would be nice to have.
- None for compiled default
- PHP for php.ini-*
Previous example codes became:
?php
// Code uses current API
?
?php
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
Issue would be codes that assume PHP
functions/classes/interfaces/constants
are
defined in global(root) namespace. (e.g. \strlen()) This could be
workaround by allowing
use aliasing to global(root) namespace. (e.g. use PHP\Legacy as
\;) In
this case,
current functions/classes/interfaces may stay in global(root) namespace.
(or use PHP as \;)
Programmers may shoot their own foot by this. This is the trade off of
flexibility.
Any thoughts and/or comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
hi,
I think it would make sense to announce that the php namespace is reserved
for internal use, but I don't think that we are ready for moving
everything
under namespaces.
For what it's worth, the manual already states that the php namespace is
reserved for us.[1]
hehe, was trying to check that before sending the mail, but couldn't find
it, thanks!
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP namespace?
On 28 Jul 2014, at 03:58, Yasuo Ohgaki yohg...@ohgaki.net wrote: If it is changed to use its own namespace, user space APIs may be changed flexible and user controlled manner. Thus, PHP may have - Consistent naming - Consistent parameter order - Graceful function/class/interface deprecation (We know what we should do for these, right?) without much compatibility issues. I really don’t like this idea. This has been suggested already for the primitive type (string and array) functions. However, I must concur with Nikita when I say that I’d much rather write $foo-split() than string\split($foo). See: http://nikic.github.io/2014/03/14/Methods-on-primitive-types-in-PHP.html Introducing a load of aliases in namespaces might lead to consistency, sure, but now there’s more characters you need to type, and aside from consistency there’s not that much benefit. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP namespace?
On Mon, 28 Jul 2014, Ferenc Kovacs wrote: I think it would make sense to announce that the php namespace is reserved for internal use, but I don't think that we are ready for moving everything under namespaces. http://php.net/manual/en/userlandnaming.php could indeed do with some updates! cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP namespace?
If it is changed to use its own namespace, user space APIs may be changed flexible and user controlled manner. Thus, PHP may have - Consistent naming - Consistent parameter order - Graceful function/class/interface deprecation (We know what we should do for these, right?) I do not support it for consistent naming or parameter order by themselves; this would likely create more confusion. However I see value in creating new APIs for certain operations such as sorting, mapping, reducing and filtering. These new APIs could work on both arrays and traversables and provide a more cohesive API. This would 'fix' several bug reports dealing with array functions that you can't pass traversables or array-like objects to where you would reasonably expect to be able to. When creating these functions we could be careful to create consistent naming conventions and consistent parameter orders, but again I consider this a side-effect rather than a reason. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP namespace?
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion would be
nice
to have.
Currently, PHP module functions/classes/interfaces are using global(root)
namespace.
If it is changed to use its own namespace, user space APIs may be changed
flexible and user controlled manner. Thus, PHP may have
- Consistent naming
- Consistent parameter order
- Graceful function/class/interface deprecation
(We know what we should do for these, right?)
without much compatibility issues.
PHP namespace may be used to provide PHP(and 3rd party)
functions/classes/interfaces/constants.
PHP\Legacy (or whatever) may be used for legacy
functions/classes/interfaces/constants.
From PHP 5.6, userland function aliasing can be done with namespace.
Following code overrides existing function.
?php
use function \mb_strlen as strlen;
var_dump(strlen('日本語'));
?
Result:
int(3)
It's good to use prefered API, but it requires use for every function
APIs to be overridden.
Note: Classes/Interfaces may override by use one by one also.
With PHP and PHP\Legacy namespace, user may write:
?php
namespace PHP; // Use current PHP functions/classes/interfaces/constants
// Code uses current API
?
?php
namespace PHP;
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
For compatibility, default namespace setting would be nice to have.
- None for compiled default
- PHP for php.ini-*
Previous example codes became:
?php
// Code uses current API
?
?php
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
Issue would be codes that assume PHP functions/classes/interfaces/constants
are
defined in global(root) namespace. (e.g. \strlen()) This could be
workaround by allowing
use aliasing to global(root) namespace. (e.g. use PHP\Legacy as \;) In
this case,
current functions/classes/interfaces may stay in global(root) namespace.
(or use PHP as \;)
Programmers may shoot their own foot by this. This is the trade off of
flexibility.
Any thoughts and/or comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
