Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39949
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.16 cause and error)
To: internals@lists.php.net
Date: Thu, 14 Aug 2008 00:27:53 -0500
User-Agent: KMail/1.9.9
References: <909776579.20080803142659@marcus-boerger.de> <48A36617.5010803@lerdorf.com> <D2E02683-76AF-43F9-8EFE-7BDB297F8BA8@pooteeweet.org>
In-Reply-To: <D2E02683-76AF-43F9-8EFE-7BDB297F8BA8@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID: <200808140027.53442.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Inconsistencies in 5.3
From: larry@garfieldtech.com (Larry Garfield)

On Wednesday 13 August 2008 6:00:21 pm Lukas Kahwe Smith wrote:

> >> Currently, if you include a file within a class method that contains
> >> function definitions, they remain functions outside the class.  If
> >> you
> >> include a file that contains a class.
> >>
> >> In short, only global cpde is executed in the scope, and there is no
> >> precedent in PHP to redefine re-usable elements based on scope.
> >>
> >> Why would namespaces be any different?  This whole argument makes no
> >> sense to me.
> >
> > Well, it depends how you view the scope.  If you include a file that
> > defines a variable from within a function or a method, that variable
> > becomes function-scoped, not global.  In the case of a namespaced
> > function or method including a file containing functions or classes,
> > those classes become global.  That has, of course, always been the
> > case, but we haven't had the concept of a namespace context before
> > and we haven't had anything that was file-scoped like this.  So
> > people might extrapolate from the function-context case to this and
> > assume the wrong thing.  That's what Marcus' patch it about.
> >
> > I happen to disagree with him and I think we should just write
> > really good docs explaining how namespaces work and provide a lot of
> > examples.
>
> My previous comments were wrong. Sorry about causing confusion. As
> Rasmus points out what Marcus is trying to solve with the warning is
> the false expectation that something that is included in a namespace
> would also be namespaced. This is not the case. As such if you want
> the included code to be in some namespace you have to explicitly do so
> in the file that is being included.
>
> As such I also agree that we do not need a warning. It will do at
> least as much harm to legitimate uses as it tries to solve for
> illegitimate uses. And those problematic users will hopefully decide
> to read out docs ..
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org

=46rom a developer perspective, I do not expect the code's namespace to be=
=20
dependent on how it's included either.  Especially with the non-braces synt=
ax=20
implemented currently, and the way includes of files with function/class=20
definitions work now, I expect them to be globally defined, which is what=20
happens. =20

I would also note that "include up front and have a good autoload scheme"=20
works great if you are writing all classes.  If you're trying to use=20
namespaces and functions, there is no autoload.  That makes the autoload=20
argument moot, and pre-loading everything up front can get ridiculously=20
expensive in large systems, and even then you don't always know what to loa=
d=20
up front.  (Think anything that accepts plugins.)  So an answer of "well if=
=20
it throws a warning when you do that, don't do that" is simply not realisti=
c=20
in practice. =20

=2D-=20
Larry Garfield
larry@garfieldtech.com