On 03.01.2009, at 15:47, Marcus Boerger wrote:
However if that is the intention, then something we might want to look
into in order to make it easier for those people is to fix something
that propbably looks wrong to them. That is binding a closure to a
property outside of the scope of the objec
Hi Johannes,
foo = "foo";$o->foo(); //Example 1
$o->bar = function(){}; $o->bar(); //Example 2
?>
The example 1 must not work, because PHP tries to call $o->foo() as a
function, but not $o->foo as description for the function.
To make example 2 working, the declaration has to be cha
Hi,
On Sat, 2009-01-03 at 15:47 +0100, Marcus Boerger wrote:
> > I'd say it would be good to concentrate on making 5.3 stable and then
> > see how new features are accepted. If users really demand such a
> > functionality, when using closures for "real life" development, we can
> > still add it, b
Hello all,
current state of the patch is attached.
marcus
Saturday, January 3, 2009, 3:47:44 PM, you wrote:
> Hello Johannes,
> Friday, January 2, 2009, 7:16:32 PM, you wrote:
>> Hi,
>> On Wed, 2008-12-31 at 17:38 +0100, Marcus Boerger wrote:
>>> So far it is. Yet I as much as you do not l
Hello Johannes,
Friday, January 2, 2009, 7:16:32 PM, you wrote:
> Hi,
> On Wed, 2008-12-31 at 17:38 +0100, Marcus Boerger wrote:
>> So far it is. Yet I as much as you do not like the inconsistency. So I
>> spend a little bit on providing the following patch that should do
>> what
>> you were loo
Hi,
On Wed, 2008-12-31 at 17:38 +0100, Marcus Boerger wrote:
> So far it is. Yet I as much as you do not like the inconsistency. So I
> spend a little bit on providing the following patch that should do
> what
> you were looking for.
I thought bout this issue for one day or so, there are three th
Hello David,
Friday, January 2, 2009, 8:03:22 AM, you wrote:
> Marcus,
> thanks!
> Why is it
> Test::{closure}()
> {closure}()
> and not
> Test::{closure}()
> Test::{closure}()
> in that test, though? Is it because func1() "was there" from the
> Engine's POV after the ctor was called? AFAIC
Marcus,
thanks!
Why is it
Test::{closure}()
{closure}()
and not
Test::{closure}()
Test::{closure}()
in that test, though? Is it because func1() "was there" from the
Engine's POV after the ctor was called? AFAICT, that's the only
difference between the two.
Cheers,
- David
On 01.01.20
Hello David,
I added test closure_037.phpt to demonstrate this.
marcus
Thursday, January 1, 2009, 5:23:08 PM, you wrote:
> Hi folks,
> first of all, thank you Marcus for implementing this. Very cool.
> As for the __get()/__getClosure() stuff, I don't think it's necessary
> or even an issu
Hi folks,
first of all, thank you Marcus for implementing this. Very cool.
As for the __get()/__getClosure() stuff, I don't think it's necessary
or even an issue. One can never simply do $this-
>getOverloadPropertyWithInvoke() anyway, because if the prop is not
there, a fatal error would be
Hello Hannes,
as discussed online. At the moment we should not have any __get()
calls during method resolution. The newly updated patch does that
now. And I think we are now safe to submit.
In the future we could think of adding __getClosure() which would be
called to resolve a dynamic closure.
Hello Hannes,
Wednesday, December 31, 2008, 8:33:43 PM, you wrote:
> On Wed, Dec 31, 2008 at 20:12, Marcus Boerger wrote:
>> Hello Lars,
>>
>> Wednesday, December 31, 2008, 6:59:08 PM, you wrote:
>>
>>> Hi Markus,
>>
>>> have you measured the performance impact in a class with - say - ten
>>> me
On Wed, Dec 31, 2008 at 20:12, Marcus Boerger wrote:
> Hello Lars,
>
> Wednesday, December 31, 2008, 6:59:08 PM, you wrote:
>
>> Hi Markus,
>
>> have you measured the performance impact in a class with - say - ten
>> methods? And what to do with __get() and __call()? How are the
>> prioritized in
Hello Lars,
Wednesday, December 31, 2008, 6:59:08 PM, you wrote:
> Hi Markus,
> have you measured the performance impact in a class with - say - ten
> methods? And what to do with __get() and __call()? How are the
> prioritized in the method resolve order?
Translated into user code we now have:
Hi Markus,
have you measured the performance impact in a class with - say - ten
methods? And what to do with __get() and __call()? How are the
prioritized in the method resolve order?
cu, Lars
Am Mittwoch, den 31.12.2008, 17:38 +0100 schrieb Marcus Boerger:
> Hello David,
>
> Tuesday, December
Marcus Boerger schrieb:
> Oh I hate that case insensitivity and inconsistency
I am all for reducing inconsistencies (and not introducing new ones :-).
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867
Hello David,
Tuesday, December 23, 2008, 5:02:43 PM, you wrote:
> Hi folks,
> I played with __invoke today:
> class Curry
> {
>protected $callable;
>protected $args;
>public static function create($callable)
>{
> $curry = new self($callable, array_slice(func_get_args(), 1)
Hi Jack,
Am Montag, den 29.12.2008, 07:09 + schrieb Jack Allnutt:
[...]
> It seems like it'd make more sense to allow *all* functions to be
> called using the 'normal' syntax without having to resort to that
> userland workaround.
Sometimes I really wish people would read the mails sent to th
Etienne Kneuss wrote:
Finally, note that you can do that in userland using something looking like:
public function __call($name, $args) { return
call_user_func_array(array($this->$name, "__invoke"), $args); }
It seems like it'd make more sense to allow *all* functions to be called
using the 'nor
Hello,
On Mon, Dec 29, 2008 at 6:00 AM, David Zülke
wrote:
> On 25.12.2008, at 06:11, Lars Strojny wrote:
>
>> Hi David,
>>
>> Am Dienstag, den 23.12.2008, 17:02 +0100 schrieb David Zülke:
>> [...]
>>>
>>> This gives a fatal "Call to undefined method DateTime::getAtom()"
>>> $d = new DateTime();
On 25.12.2008, at 06:11, Lars Strojny wrote:
Hi David,
Am Dienstag, den 23.12.2008, 17:02 +0100 schrieb David Zülke:
[...]
This gives a fatal "Call to undefined method DateTime::getAtom()"
$d = new DateTime();
$d->getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $d->getAtom(
PHP written in a JavaScript style is already possible with PHP 5.3. I
started a little
thread about this on a forum but didn't get that much feedback:
http://www.sitepoint.com/forums/showthread.php?t=565576
It's not really what we're used to in JavaScript but it's very close.
On 12/25/2008 0
Hi David,
Am Dienstag, den 23.12.2008, 17:02 +0100 schrieb David Zülke:
[...]
> This gives a fatal "Call to undefined method DateTime::getAtom()"
>$d = new DateTime();
>$d->getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
>echo $d->getAtom();
This is the same as the following:
Hi!
This gives a fatal "Call to undefined method DateTime::getAtom()"
$d = new DateTime();
$d->getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $d->getAtom();
This syntax means "call method getAtom of object $d". PHP has no way of
reusing same syntax for two different thing
Hi folks,
I played with __invoke today:
class Curry
{
protected $callable;
protected $args;
public static function create($callable)
{
$curry = new self($callable, array_slice(func_get_args(), 1));
return $curry;
}
protected function __construct($callable, $args)
{
$t
25 matches
Mail list logo
