Hi,
I couldn't find any information on this elsewhere, or perhaps I didn't look
hard enough. Its been bugging me a while though so I though I would ask.
Has there been any discussion or consideration towards migrating or at
least aliasing all built in classes to a Php vendor namespace?
For aesthetics if nothing else.
AFAIK the PHP namespace is the root one.
Lorenzo
2015-06-03 10:33 GMT+02:00 Dominic Grostate codekestrel@googlemail.com:
Hi,
I couldn't find any information on this elsewhere, or perhaps I didn't look
hard enough. Its been bugging me a while though so I though I would ask.Has there been any discussion or consideration towards migrating or at
least aliasing all built in classes to a Php vendor namespace?For aesthetics if nothing else.
Yes, however for consistency, I personally like the idea of using a longer
namespace over prefixed class names. The most relevant example being the
SPL data structures.
For instance SplStack might come under Php\Collection\Stack.
As far as I can tell there is a fair amount of fear of adding new native
classes in light of BC issues. But I have yet to see anyone claim the Php
vendor namespace for themselves, so it might provide for future extensions.
Dominic
AFAIK the PHP namespace is the root one.
Lorenzo
2015-06-03 10:33 GMT+02:00 Dominic Grostate codekestrel@googlemail.com:
Hi,
I couldn't find any information on this elsewhere, or perhaps I didn't
look
hard enough. Its been bugging me a while though so I though I would ask.Has there been any discussion or consideration towards migrating or at
least aliasing all built in classes to a Php vendor namespace?For aesthetics if nothing else.
Dominic Grostate wrote on 03/06/2015 09:33:
Hi,
I couldn't find any information on this elsewhere, or perhaps I didn't look
hard enough. Its been bugging me a while though so I though I would ask.Has there been any discussion or consideration towards migrating or at
least aliasing all built in classes to a Php vendor namespace?For aesthetics if nothing else.
The "PHP" namespace (and all sub-namespaces thereof) is officially
reserved for "internal language use", but to date there has been no
comprehensive plan of how to lay it out...
On Wed, Jun 3, 2015 at 1:33 AM, Dominic Grostate
codekestrel@googlemail.com wrote:
Has there been any discussion or consideration towards migrating or at
least aliasing all built in classes to a Php vendor namespace?
Not any that's led to a consensus.
Personally, I like the idea of moving EVERYTHING to PHP\ at once and
building in an automatic fallback, so an app could do:
<?php
$dt = new DateTime(...); // uses builtin DataTime via fallback to PHP namespace
Or:
<?php
class DateTime { ... }
$mydt = new DateTime(...); // Uses user supplied DateTime
$pdt = new PHP\DateTime(...); // Uses builtin DateTime
Possibly paired with the ability to import a NS to root:
<?php
use PHP as ;
$pdt = new DateTime(...); // Uses builtin DateTime from root namespace
I don't feel strongly about any of this though, so I'm not personally
inclined to push any RFC to make it happen.
-Sara
Hi all,
On Wed, Jun 3, 2015 at 1:33 AM, Dominic Grostate
codekestrel@googlemail.com wrote:Has there been any discussion or consideration towards migrating or at
least aliasing all built in classes to a Php vendor namespace?Not any that's led to a consensus.
Personally, I like the idea of moving EVERYTHING to PHP\ at once and
building in an automatic fallback, so an app could do:<?php
$dt = new DateTime(...); // uses builtin DataTime via fallback to PHP
namespaceOr:
<?php
class DateTime { ... }
$mydt = new DateTime(...); // Uses user supplied DateTime
$pdt = new PHP\DateTime(...); // Uses builtin DateTime
It's acceptable option, but I prefer explicit declaration for clean root
namespace.
Possibly paired with the ability to import a NS to root:
<?php
use PHP as ;
$pdt = new DateTime(...); // Uses builtin DateTime from root namespace
+1 for "as "
It achieves both clean namespace and compatibility at the same time.
It opens door for easier API version up also. Automatic fallback disturbs
this.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
On Wed, Jun 3, 2015 at 1:33 AM, Dominic Grostate
codekestrel@googlemail.com wrote:Has there been any discussion or consideration towards migrating or at
least aliasing all built in classes to a Php vendor namespace?Not any that's led to a consensus.
Personally, I like the idea of moving EVERYTHING to PHP\ at once and
building in an automatic fallback, so an app could do:<?php
$dt = new DateTime(...); // uses builtin DataTime via fallback to PHP
namespaceOr:
<?php
class DateTime { ... }
$mydt = new DateTime(...); // Uses user supplied DateTime
$pdt = new PHP\DateTime(...); // Uses builtin DateTimeIt's acceptable option, but I prefer explicit declaration for clean root
namespace.Possibly paired with the ability to import a NS to root:
<?php
use PHP as ;
$pdt = new DateTime(...); // Uses builtin DateTime from root namespace+1 for "as "
It achieves both clean namespace and compatibility at the same time.
It opens door for easier API version up also. Automatic fallback disturbs
this.
This one is not compatible with current code as you have to alias the
PHP namespace to the root one before using full classes like \DateTime.
PS: I like a lower case "php" much more than upper case "PHP" ;)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Marc,
This one is not compatible with current code as you have to alias the PHP
namespace to the root one before using full classes like \DateTime.
Right.
We are better to have PHP namespace for internal classes/functions first,
then
introduce "as " few years later. i.e. PHP classes/functions exist in both
\ and \php
namespace during migration period or we may user INI switch for migration.
PS: I like a lower case "php" much more than upper case "PHP" ;)
I'm neutral on this :)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I've missed out on most of this discussion via email, bit I've watching the
threads anyway. It seems to me the main debate is about backwards
compatibility, and where the classes belong.
My reason for starting this thread was not really out of necessity, but
merely to argue semantics. So if it is not worth it then it is not worth it.
However, given that some people here appear receptive to the idea I'd like
to support my original suggestion of aliasing by comparing the concept to
JavaScript, where by the root namespace is an alias of the window object
(or vice versa). It could be used as a permanent alias, or only as a
solution for phasing out the global namespace in preparation for PHP8 in X
number of years.
Hi all,
On Wed, Jun 3, 2015 at 1:33 AM, Dominic Grostate
codekestrel@googlemail.com wrote:Has there been any discussion or consideration towards migrating or at
least aliasing all built in classes to a Php vendor namespace?Not any that's led to a consensus.
Personally, I like the idea of moving EVERYTHING to PHP\ at once and
building in an automatic fallback, so an app could do:<?php
$dt = new DateTime(...); // uses builtin DataTime via fallback to PHP
namespaceOr:
<?php
class DateTime { ... }
$mydt = new DateTime(...); // Uses user supplied DateTime
$pdt = new PHP\DateTime(...); // Uses builtin DateTimeIt's acceptable option, but I prefer explicit declaration for clean root
namespace.Possibly paired with the ability to import a NS to root:
<?php
use PHP as ;
$pdt = new DateTime(...); // Uses builtin DateTime from root namespace+1 for "as "
It achieves both clean namespace and compatibility at the same time.
It opens door for easier API version up also. Automatic fallback disturbs
this.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net