On Thursday 22 January 2009 8:21:28 am Christian Seiler wrote:
> Hi everybody,
>
> We had that chat that Lukas announced yesterday and I promised Lukas to
> sum up the results of that chat.
>
> Problem was: There were only four people really there: Stas, Lukas,
> David and me. Lukas was interested
Hi everybody,
We had that chat that Lukas announced yesterday and I promised Lukas to
sum up the results of that chat.
Problem was: There were only four people really there: Stas, Lukas,
David and me. Lukas was interested in getting results in order to be
able to release PHP 5.3 beta 1, Stas and
Hi Marcus,
I've just got an idea how prototyping may be implemented without magic
you solution had. We can use a special function
function attach_method($object, $name, $closure);
This function should clone the $closure bind $this of clone of $closure
to $object and assign it into $object->n
On 21.01.2009, at 10:04, David Zülke wrote:
Am 20.01.2009 um 18:41 schrieb Christian Seiler:
Hi,
maybe an IRC meeting is the easiest way to come to an agreement. How
about tomorrow evening 21:00 CEST in #php.closures on freenode?
Just for clarification: I assume you mean Wednesday, Januar
Am 20.01.2009 um 18:41 schrieb Christian Seiler:
Hi,
maybe an IRC meeting is the easiest way to come to an agreement. How
about tomorrow evening 21:00 CEST in #php.closures on freenode?
Just for clarification: I assume you mean Wednesday, January 21st,
19:00
UTC (CEST == UTC+2) and thus 2
Hi!
maybe an IRC meeting is the easiest way to come to an agreement. How
about tomorrow evening 21:00 CEST in #php.closures on freenode?
ok
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Dev
Hi,
> maybe an IRC meeting is the easiest way to come to an agreement. How
> about tomorrow evening 21:00 CEST in #php.closures on freenode?
Just for clarification: I assume you mean Wednesday, January 21st, 19:00
UTC (CEST == UTC+2) and thus 20:00 CET? Would be fine with me.
Regards,
Christian
Hi,
maybe an IRC meeting is the easiest way to come to an agreement. How
about tomorrow evening 21:00 CEST in #php.closures on freenode?
regards.
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
class Foo {
private $myVeryOwnData;
function bla {
$this->bigMEss = function () { return $this->myVeryOwnData; }
}
}
This is not a "mess" - this is *exactly* what closures are for. If you
don't want this function to be able to access private variables - do not
put code that acc
Hi Marcus,
> And I could say that what the two of you designed ofr PHP is not a design
> but a very confusing incoherent implementation that is based on the lack
> of being able to get support for something else in the underlying c
> implementation.
Huh? The current implementation is by d
Hello Stanislav,
Monday, January 19, 2009, 9:32:09 AM, you wrote:
> Hi!
>> It is a mess right now. You assign a closure to another method and get
>> access to the original owners private members. That is not only unexpected
> Could you give a code example? I'm not sure I understand what you mea
Hello Christian,
Sunday, January 18, 2009, 11:58:29 PM, you wrote:
> Hi Marcus,
>>> "Convoluted"? "Mess"? Are you kidding me? It's standard usage of access
>>> handlers.
>>
>> It is a mess right now. You assign a closure to another method and get
>> access to the original owners private member
Hi!
It is a mess right now. You assign a closure to another method and get
access to the original owners private members. That is not only unexpected
Could you give a code example? I'm not sure I understand what you mean
by access (or "assign closure to a method" for that matter) - if access
Hi Marcus,
>> "Convoluted"? "Mess"? Are you kidding me? It's standard usage of access
>> handlers.
>
> It is a mess right now. You assign a closure to another method and get
> access to the original owners private members. That is not only unexpected
> and contradicting anything that any oyther
Hello Stanislav,
Wednesday, January 14, 2009, 5:29:02 PM, you wrote:
> Hi!
>> That is one example of convoluted code that is already possible. If a
>> developer creates such a mess is his fault.
> "Convoluted"? "Mess"? Are you kidding me? It's standard usage of access
> handlers.
It is a mes
Hi,
Ok, my proposal to drop OO support from Closures was exactly embraced.
All I want you guys to think about is how you want to deal with this
in terms of the PHP 5.3 release. If no decision is found and
implemented over the weekend, this topic will essentially cement the
need for an add
Am 13.01.2009 um 22:58 schrieb Marcus Boerger:
5) A closure assigned to a property can be called directly rather
than just by a temporary variable:
$obj->property = function() {}
$obj->property(); // valid call
This will get us into trouble IMHO, as it would not behave too well
with
__get
On Thu, Jan 15, 2009 at 10:56:01AM +0100, Lukas Kahwe Smith wrote:
>
> We have worked through the challenge of getting namespaces worked out
> in 5.3, adding yet another increasingly heavy feature to the syntax
> would delay us if we really want to make sure we get it right.
> Screwing up wo
Hi
I have tried to catch up to the discussion yesterday evening. I must
admit its not very trivial for me to understand the entire scope of
the issues. I am especially worried about things becoming too magical
(although in general I am pro giving end users all the power in the
world). At
Hi!
Now, regardless whether is convoluted or not, you must agree that is
better having callable properties in the language and documenting that
this won't apply for overloaded properties. In the end you don't really
I do not see any aspect in which it would be better.
need callable overload
Hi,
On 1/14/2009 18:29, Stanislav Malyshev wrote:
Hi!
That is one example of convoluted code that is already possible. If a
developer creates such a mess is his fault.
"Convoluted"? "Mess"? Are you kidding me? It's standard usage of
access handlers.
I don't understand how that could be stan
Hi!
That is one example of convoluted code that is already possible. If a
developer creates such a mess is his fault.
"Convoluted"? "Mess"? Are you kidding me? It's standard usage of access
handlers.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253
On 1/14/2009 01:15, Stanislav Malyshev wrote:
Hi!
Also, this adds very new thing to PHP - objects that change while
being assigned. I am not sure it is a good thing.
Well Closures are a brand new thing in PHP. So far we had nothing even
remotely close to the closures we have right now.
Th
just a note about it
in javascript, "this" ($this in php) is a special variable in closure,
"this" is always bound to the "object" of "object.method(...)" when it
is called, whenever i want a "this" of closure creation time context,
i use:
var _this = this;
return function() { _this.prop = 123; _th
Hi!
Also, this adds very new thing to PHP - objects that change while being
assigned. I am not sure it is a good thing.
Well Closures are a brand new thing in PHP. So far we had nothing even
remotely close to the closures we have right now.
There are a lot of different features in PHP, that'
Hello Stanislav,
Tuesday, January 13, 2009, 12:07:31 AM, you wrote:
> Hi!
>> 1) a non static closure assigned to an instance changes the closures
>> this to be set to the actual object:
> I'm not sure why would you expect this. If you have closure that has
> some bound $var inside, and you use
Hello,
On Tue, Jan 13, 2009 at 12:07 AM, Stanislav Malyshev wrote:
> Hi!
>
>> 1) a non static closure assigned to an instance changes the closures
>> this to be set to the actual object:
>
> I'm not sure why would you expect this. If you have closure that has some
> bound $var inside, and you use
Hi!
1) a non static closure assigned to an instance changes the closures
this to be set to the actual object:
I'm not sure why would you expect this. If you have closure that has
some bound $var inside, and you use it in context which has another
$var, you don't expect that $var change to ne
Hello Internals,
our new closures can easily work as prototypes and I actually thought
of simply doing it as a bug fix. But it appeared that my first attempt
was inclomplete if not to say completely wrong. It further more turned
out that not everyone is a fan of the genral idea.
Basically what
29 matches
Mail list logo
