I'll just chime in and say that I also find the current
variable-substitution idiom more "natural" than using a Reflection
class to look up a bunch of stuff...
If it's gonna kill youse guys to keep it in there with some kind of
code-maintenance nightmare, fine, kill it.
But if not, having two way
c: internals@lists.php.net
> Subject: Re: [PHP-DEV] Fix inconsistencies in OO calls
>
> Hello Sebastian,
>
> yep, you and Derick are right here. This is definitively a
> fix that should go in. Chinstrap just commit the stuff please.
>
> marcus
>
> Thursday, August 2, 2007
Hello Sebastian,
yep, you and Derick are right here. This is definitively a fix that should
go in. Chinstrap just commit the stuff please.
marcus
Thursday, August 2, 2007, 11:36:54 AM, you wrote:
> Derick Rethans schrieb:
>> I think that'd be a bad idea. I don't see a problem with this patch
Derick Rethans schrieb:
> I think that'd be a bad idea. I don't see a problem with this patch at
> all, and why should people use reflection here? As you're always so much
> for BC, I find it strange that you're suggesting to remove something
> totally harmless and instead want people to force t
ACK.
David
Am 02.08.2007 um 11:36 schrieb Sebastian Bergmann:
Derick Rethans schrieb:
I think that'd be a bad idea. I don't see a problem with this
patch at
all, and why should people use reflection here? As you're always
so much
for BC, I find it strange that you're suggesting to remov
I agree with Derick and Lukas. I find the ways this patch proviedes to be
much more "natural" and easy to learn (I personally was in a desparate need
for $classname::everything and also was wondering why it is not implemented,
and then I found the Reflection).
I'm just php developer, and I do not h
Derick Rethans wrote:
On Wed, 1 Aug 2007, Andi Gutmans wrote:
This is not really a fix. When we worked on PHP 5 we deliberately
decided to relax on all the weird dynamic constructs which didn't
provide a lot of value for the majority of use-cases. Of course the
Reflection API was going to be
On Wed, 1 Aug 2007, Andi Gutmans wrote:
> This is not really a fix. When we worked on PHP 5 we deliberately
> decided to relax on all the weird dynamic constructs which didn't
> provide a lot of value for the majority of use-cases. Of course the
> Reflection API was going to be the way to do th
ternals@lists.php.net; Ilia Alshanetsky
Subject: Re: [PHP-DEV] Fix inconsistencies in OO calls
Hi Etienne,
On Mon, 2007-07-30 at 22:27 +0200, Etienne Kneuss wrote:
Hello,
Currently, those are allowed:
new $classname;
classname::$methodname();
but those aren't:
$classname::foo();
$clas
age for the old way which refers you to the
Reflection API?
Andi
> -Original Message-
> From: Johannes Schlüter [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 31, 2007 4:57 AM
> To: Etienne Kneuss
> Cc: internals@lists.php.net; Ilia Alshanetsky
> Subject: Re: [PHP-DEV
Hi Etienne,
On Mon, 2007-07-30 at 22:27 +0200, Etienne Kneuss wrote:
> Hello,
>
> Currently, those are allowed:
>
> new $classname;
> classname::$methodname();
>
> but those aren't:
>
> $classname::foo();
> $classname::CONST;
> $classname::$member;
>
> Here is a patch for head that fixes thos
Hello,
Currently, those are allowed:
new $classname;
classname::$methodname();
but those aren't:
$classname::foo();
$classname::CONST;
$classname::$member;
Here is a patch for head that fixes those inconsistencies by extending
the language parser to support such syntax:
http://patches.cold
12 matches
Mail list logo
