On 16/Sep/10 8:49 PM, Stas Malyshev wrote:
No, we can't have python decorators because unlike Python PHP functions
and classes aren't first-class objects. In Python, this:

@dec2
@dec1
def func(arg1, arg2, ...):
pass

means this:

def func(arg1, arg2, ...):
pass
func = dec2(dec1(func))

However, you can't write equivalent code in PHP.

I had the same idea regarding decorators, and I saw the same problem that you see, functions are not first-class citizens in PHP. I was wondering, though, whether the possibility to assign expressions to constants couldn't change that. Let me explain a little what I'm thinking exactly.

Currently, PHP supports lambda expressions and they're pretty much as first-class citizens as possible. PHP, also supports variable functions in an attempt to make global functions look like they'd be first-class citizens.

So, the following snippet isn't yet working, but AFAIK it will work in the next PHP release:


function foo() {
    echo "foo was called";
}

function bar() {
    return 'foo';
}

bar()(); // prints "foo was called";


Now, assume I define this constant:

define('foo', 'foo');

Now I can write:


function bar() {
    return foo;
}

And the "foo" function will look more like a first-class citizens.
But, how about being able to write:

const foo = function () use ($globalVar) {

};

which would be the desugaring of:

function foo () {
    global $globalVar;
}

Now foo would be an instance of Closure, and would allow us to pass it around free.


Does that make any sense to any of you? Is it at least possible with the current Zend Engine implementation? What problems would it pose?


Getting back to decorators...

Having the above syntax, we would be able to write:

const func = dec2(dec1(function () {

}));

which can be further sugared to some decorator specific syntax.


I guess the gist of my whole email is that it would be nice to get rid of the dollar sign in identifiers that designate lambda expressions. That would somehow level things up.

--
IonuČ› G. Stan  |  http://igstan.ro

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to