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.
On 4 Jun 2015 9:02 am, "Yasuo Ohgaki" <yohg...@ohgaki.net> wrote:
> Hi all,
>
> On Thu, Jun 4, 2015 at 12:07 AM, Sara Golemon <poll...@php.net> wrote:
>
>> On Wed, Jun 3, 2015 at 1:33 AM, Dominic Grostate
>> <codekest...@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
>>
>
> 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
> yohg...@ohgaki.net
>
>
