Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31367
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.132.245 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=E1HFoj4v1olcZtTXHGNri84sJaxsurj7+xa2C1Yy2Tq4sIpCi3U53U7Tki7iwBBUCgfpfsykXw9IFjNWL/Yf/enw4D5/c+A7cgWXmxzSoO8vUTXQjTU0qCNSRE5y79mLJ74RFx7uIl4XGfFAPbyeQAxWe730KBA/2OQffsLrM+U=
Message-ID: <261daaa10708020230w550b30d8qf587f4b6bc7afefc@mail.gmail.com>
Date: Thu, 2 Aug 2007 09:30:22 +0000
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>
Cc: "Derick Rethans" <derick@php.net>, "Andi Gutmans" <andi@zend.com>, 
	"=?UTF-8?Q?Johannes_Schl=C3=BCter?=" <johannes@php.net>, 
	"Etienne Kneuss" <colder@php.net>, internals@lists.php.net, 
	"Ilia Alshanetsky" <ilia@prohost.org>
In-Reply-To: <46B18C41.5010408@pooteeweet.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_110716_1780451.1186047022450"
References: <46AE49B3.2070100@php.net> <1185883035.23889.31.camel@johannes.nop>
	 <698DE66518E7CA45812BD18E807866CE7C10BB@us-ex1.zend.net>
	 <alpine.DEB.0.98.0708020913130.26720@kossu.ez.no>
	 <46B18C41.5010408@pooteeweet.org>
Subject: Re: [PHP-DEV] Fix inconsistencies in OO calls
From: kenashkov@gmail.com ("Vesselin Kenashkov")

------=_Part_110716_1780451.1186047022450
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 have experiance with other languages,
but still I think the way it is implemented in the patch is the "natural"
way to do it. And if Reflection is slower and meant for introspection why to
use it for this.
Is there any specific consideration for using Reflection for this? Or was
there a discussion about this topic earlier (can somebody point me to it)?

+1 for the patch.

Vesselin Kenashkov

On 8/2/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>
> 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 the way to do these dynamic things in
> >> future. It would also simplify the engine's code. The reason why those
> >> first constructs work were for BC reasons. We didn't want to break
> >> existing code but wanted to not add on top of this.
> >>
> >> While it may feel inconsistent 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?
> >
> > 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 to use the
> > slow Reflection API which is meant for introspection...
>
> I agree its harmless and easy to learn. Moreover I do not see the
> benefit of using the Reflection API instead.
>
> @Andi: Could you explain to us why you think that this sort of thing
> should best be done through the Reflection API?
>
> regards,
> Lukas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

------=_Part_110716_1780451.1186047022450--