Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17402
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 26 Jul 2005 09:26:03 +0200
Reply-To: Marcus Boerger <mail@marcus-boerger.de>
Message-ID: <1958582676.20050726092603@marcus-boerger.de>
To: Jessie Hernandez <jrhernandez05@gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <34.C6.58254.4BD75E24@pb1.pair.com>
References: <52.31.61486.E8DCDD24@pb1.pair.com>
	<1122328113.647.16.camel@boost.home.ahk> <34.C6.58254.4BD75E24@pb1.pair.com>
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 Jessie,

  i am quite sure it tells you that you have a conflict with the ternary
operator. Look up the archives on the issue. There should also be an
example on the matter.

marcus

Tuesday, July 26, 2005, 2:02:56 AM, you wrote:

> Alex Kiesel 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.
>> 

> I am no expert in bison or yacc, so could someone look at the patch and tell
> me what, if anything, is wrong, and how to fix it?


>> 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.
>> 

> The scheme is needed in order to locate class files for the classes that
> have been imported in a full namespace import. With no convention, we're
> forced to call __autoload, and since the only thing that will be passed is
> the class name, __autoload will have no way of knowing to what namespace
> that class belongs to. With the convention, each imported namespace's
> directory can be checked to see which one contains the class file.


>> 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.)
>> 

> What Stanislav and I were discussing was not this, it was the following
> (variable class names), which is fully supported in the patch:

> <?php
> import Foo:Bar;
> $name = 'Bar';
> $obj = new $name();
?>>


> Anyways, thanks for taking the time to try out the patch! Let me know if you
> have any other ideas/suggestions. 

> --
> Jessie




-- 
Best regards,
 Marcus                            mailto:mail@marcus-boerger.de