Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17398
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 25 Jul 2005 23:59:18 +0200
Reply-To: Marcus Boerger <mail@marcus-boerger.de>
Message-ID: <538910800.20050725235918@marcus-boerger.de>
To: Alex Kiesel <alex@kiesel.name>
Cc: Jessie Hernandez <jrhernandez05@gmail.com>,
	internals@lists.php.net
In-Reply-To: <1122328113.647.16.camel@boost.home.ahk>
References: <52.31.61486.E8DCDD24@pb1.pair.com>
	<1122328113.647.16.camel@boost.home.ahk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Namespace Patch, Alpha 3
From: mail@marcus-boerger.de (Marcus Boerger)

Hello Alex,

Monday, July 25, 2005, 11:48:33 PM, you wrote:

> Hi Jessie,

> first, while your patch applied cleanly (except zend_vm_opcodes.h, which
> is generated) the build broke with:
> bison -y -p zend -v -d
> /mnt/home/alex/cvs/php-namespaces/Zend/zend_language_parser.y -o
> Zend/zend_language_parser.c
> conflicts:  5 shift/reduce
> /mnt/home/alex/cvs/php-namespaces/Zend/zend_language_parser.y: expected 4 shift/reduce conflicts
> *** Error code 1

> I had to increase the expected shift/reduce conflict count to 5 to
> continue the build, which then completed successfully.

> On Wed, 2005-07-20 at 00:05 -0400, Jessie Hernandez wrote:
>> Also, import statements now include the class files, using a new .ini
>> variable, "class_path". Files under the directories in the class_path have
>> the namespace names as directories and the class names named exactly as the
>> file that declares it (like Java), e.g. my_ns:class1 is declared in
>> $class_path/my_ns/class1.php.

> 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.

>> Again, the only missing feature I know of is "namespace imports". I've been
>> thinking about it, and I think the best approach is actually very simple.

> 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.

Best regards,
 Marcus                            mailto:mail@marcus-boerger.de