Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46443
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.220.227 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type;
        b=fr/acRZ5Fot0m14ot9bAfQsoVQ8w+tWO3FpyraiH30PtI3EP8JyytKd9ifbZvy+9ro
         I7Rt8Eq6CI58bRlQBKrHJi8NJLL18dqmld9wYIPXY9OPUEJSwy17CvTlwtFyS6aBlARq
         ZJlO2rmLHMzO15r6/33NgBwdmhKIv6ETsyoSI=
MIME-Version: 1.0
Reply-To: RQuadling@googlemail.com
In-Reply-To: <4B27DD0B.1070303@gmx.net>
References: <4B01A4C2.8030602@gmx.net> <4B27DD0B.1070303@gmx.net>
Date: Wed, 16 Dec 2009 10:00:59 +0000
Message-ID: <10845a340912160200q72ed4999jc0c956ded788b8ff@mail.gmail.com>
To: Christian Seiler <chris_se@gmx.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Closures and $this
From: rquadling@googlemail.com (Richard Quadling)

2009/12/15 Christian Seiler <chris_se@gmx.net>:
> Hello again,
>
>> Discuss away!
>
> I'm a little disappointed by the non-outcome of this debate. Very few
> people have responded and most of them seem to agree proposal (A) should
> be implemented, perhaps with the additional bind/bindTo as in my
> proposal and perhaps not.
>
> The problem here is: (A) was exactly the thing that was implemented and
> that people started to have a problem with as soon as the first or
> second beta of PHP 5.3 was released. And because the feedback came in so
> late, Lukas & Johannes decided to remove $this support from closures for
> PHP 5.3 in order to be able to decide that later on.
>
> So basically we're at the same point where we were a little more year
> ago: There's an RFC for this (the semantics of $this support were
> discussed in the original closures RFC!) and the people who read it on
> internals@ support it. However, I predict that if we implement exactly
> the semantics that the RFC proposes, we will get into the same
> discussion we had with PHP 5.3 just before the release of PHP 6... (or
> 5.4 should there be one).
>
> So: What now?
>
> Regards,
> Christian
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

How much of a use case is binding $this to closures (personally, I
think this is quite a common usage, but I've been using JavaScript so
maybe I've got the wrong head on).

But, if there are significant technical/internal issues with regard to
binding $this to closures, what about (and I'm expecting the usual
shoot down here as I obviously know squat) NOT binding closures at all
(option 0).

Instead get traits working.

A trait (as I understand things from the rfc) from a userland
perspective seems to offer some very similar features of bound
closures. Binding a closure to an object, to all intents and purposes
extends the object with a new callable method. Traits do that too.
Completely differently - agreed - but a class with a trait has a new
method. An object with a bound closure has a new method (ish).

I know there are differences, but because it had been previously
decided to NOT include bound closures, changing that (surely only at 6
or at a BIG push 5.4 if and when) would have to be considered so not
to break BC (though I can't really see how allowing $this to be bound
would break BC as you can't bind $this at the moment).

At this late stage, is this a realistic option?

If this _IS_ an option then I'd vote for this. I'd much rather have
traits than bound closures.

Regards,

Richard.


-- 
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling