Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17416
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: Marcus Boerger <mail@marcus-boerger.de>
Cc: Jessie Hernandez <jrhernandez05@gmail.com>, internals@lists.php.net
In-Reply-To: <538910800.20050725235918@marcus-boerger.de>
References: <52.31.61486.E8DCDD24@pb1.pair.com>
	<1122328113.647.16.camel@boost.home.ahk>
	<538910800.20050725235918@marcus-boerger.de>
Content-Type: text/plain
Date: Tue, 26 Jul 2005 23:14:27 +0200
Message-ID: <1122412467.4938.7.camel@boost.home.ahk>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Namespace Patch, Alpha 3
From: alex@kiesel.name (Alex Kiesel)

On Mon, 2005-07-25 at 23:59 +0200, Marcus Boerger wrote:
> > I don't like this idea; it restricts the developer to this Java-like
> > class / directory layout. It also restricts him to name his files after
> > the scheme you defined (which is <classname>.php) - many use other
> > schemes. Shouldn't PHP let you be free in this kind of decision? I think
> > yes, especially, as this could also be implemented with the __autoload
> > function in user-space.
> 
> You already have the ability to overload __autoload or provide several
> userspace __autoload functions that would be called one after another
> until the first succeeds. What else do you want? Besides the fact that
> i am still convinced that we should find a way to pass the full namespaced
> name to __autoload instead of just the classname. If you ask me not doing
> so is simply an error.

Yes, I was saying to use __autoload instead of the proposed import
magic.

> > Here's another one: the script
> 
> > <?php
> >   $foo= 'Foo:Bar';
> >   import $foo;
> ?>>
> 
> > gives me
> 
> > alex@boost:~/cvs/php-namespaces# sapi/cli/php ~/tests/classes/dynamic_import.php
> 
> > Parse error: parse error, unexpected T_VARIABLE, expecting
> > T_NAMESPACE_NAME or T_NAMESPACE in
> > /mnt/home/alex/tests/classes/dynamic_import.php on line 3
> 
> > (IIRC Stanislav Malyshev already mentioned this in the YANP-thread
> > already.)
> 
> I don't see any reason to allow this. PHP is already far to dynamic (which
> already prevents some speed improvements to the engine). Namespaces are a
> means for working with several frameworks/libraries at a time and for
> spreading/controlling responsibilities. In all those cases you definitively
> won't need the above and its presents would circumvent what we'd achieve
> here.

import $this is just something I'd expect PHP to be able to deal with -
but I could live without it.

Btw, if you're saying "Namespaces are for spreading/controlling
responsibilities", do you mean something like the package access level
for methods and member variables Java has? Is anyone thinking of
introducing this?

-Alex