Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33701
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.146.181 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=SGa0IvuB0Ky2jpEjMbkZoixR0KWhfSTlCEHcOEc/ymRB5guyFfypKNSPCzeW9AwH6UyP+mS/LSwfFJ1nT1gMY9gRW5dVPFBjO4K7s0ij5xE1DZPS3N/7efdbXN8palfAyOUw9EiKuT9+LnPFEz2Gp+z6MmjtizsSxd2+BniybTY=
Message-ID: <b5f7bf6c0712041544j67476dc6p27195fa249d74e72@mail.gmail.com>
Date: Tue, 4 Dec 2007 18:44:46 -0500
Sender: david.coallier@gmail.com
To: "Steph Fox" <steph@zend.com>
Cc: "Derick Rethans" <derick@php.net>, 
	"PHP Developers Mailing List" <internals@lists.php.net>
In-Reply-To: <048a01c836c6$da00d010$e6dfc350@foxbox>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <alpine.DEB.0.98.0712042315260.20300@kossu.ez.no>
	 <048a01c836c6$da00d010$e6dfc350@foxbox>
Subject: Re: [PHP-DEV] RFC: Dropping Namespace
From: david.coallier@nyphp.com ("David Coallier")

On Dec 4, 2007 5:41 PM, Steph Fox <steph@zend.com> wrote:
> Hi D,
>
> >   extension (DateTime, DateTimeZone). However introducing the new class
> >   DateTimeSpan might break people's code that do things like:
> >
> > <?php
> > use myNamespace::DateTimeZone as DateTimeZone;
> > ?>
>
> Typo? I guess you meant 'DateTimeSpan' to be in there somewhere...
>
> This is I think the biggest problem with the implementation, that new
> internal classes can still break userland code. The problem of single-file
> namespacing is only a problem because of the performance implications for
> those who bundle their includes, and it _should_ be possible to find a good
> way to resolve that. I don't really see a problem with the 'use only at the
> head of the file' thing (although I know others do); in fact I prefer it,
> because it makes for an easier upgrade path.
>
> Can I just ask one thing? If namespace support is once again pulled before
> it sees the light of a release, can we _please_ document exactly what the
> problems were, loud and clear, and put the document somewhere people are
> likely to see it?
>
> Thanks,
>
> - Steph
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

I never thought it would get back to the drawing board that way, but
Derick, as I said on irc when we discussed about that, I agree with
you. With the current implementation, the namespaces should be removed
completely. Not only because it has missing features, but from the
voice that comes out of the community, it seems that some features
(important ones) (Point 2) and some PHP general concept (Point 3) are
simply not what people want.

I do not want to start a flamewar here, but again, the { } thread came
up a few days ago and again, everyone who says that they get a
performance gain by aggregating the files (Like compiled PHP files)
are being either ignored or in some way insulted... Anyways, some
people do not believe in the aggregation of the files, why's that ? I
am not quite sure, well I have a few ideas but they are not
appropriate for the mailing list, but the optimization technique that
is aggregating the files work and I would really love to see it stay
(At least the ability to decide if I want to aggregate them or not).
And this is currently not possible with the implementation.

Things like use * as * is something that is missing and a very
important feature to my eyes as well. However, this kind of feature
comes with education. If we allow people to use * as *, we have to
explain them that the namespaces are not going to be coding for you.
They might introduce the same conflicting errors as before when they
had only classes. I want to make sure people understand that
namespaces are not there to make one type less but as a great man once
said, an additional structural element that is to be used correctly in
order to work correctly.

 (You can give a nail to someone and he'll stick it in his eye instead
of building a house... but if you show him how to use the nail
correctly and with which other tools, he'll be able to build something
solid... maybe...)

From what I have experienced since the namespaces are in, my prefixing
is still the way to go to make sure I can run all my nifty
optimization scripts around and make a few "free" optimizations.

This is a thread that will probably go deep in the sand in a few days
(unless the community arises (which doesn't usually happen)) but for
the records, if anyone has anything to say, it's still the time :)

-- 
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18