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
ntainability) I'm OK with it. It's
not a big deal but being a bit more courteous wouldn't hurt you.
Andi
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 02, 2007 4:33 AM
> To: Sebastian Bergmann
> C
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
ent I still prefer the existing path. Maybe for PHP
6 we can even make an E_STRICT message 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: in
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
11 matches
Mail list logo