> On Tue, 11 Feb 2020 at 19:08, Dik Takken firstname.lastname@example.org> wrote:
>> However, wrapped inside $(), which only accepts
>> functions and methods
> I don't think I meant that. I think it still should accept variables
> as well, so it would still be ambiguous as to whether it referred to
> the value of the property Fot of object $obj, or the method Fot on the
> $obj class.
In that case, the ambiguity issue remains. I was thinking about it as a
construct for wrapping functions and methods into closures. Could you
provide an example of how accepting variables would be useful?
>> another possibility could be: closure(foo);
> That has the downside of exposing the implementation detail, that it's
> implemented through closures, which would be a regrettable choice if
> we ever decided to change the implementation details in the future.
I don't think I understand. Creating a closure is something you do
because of the specific semantics they have. The fact that it yields a
closure is not a detail, it is the reason why I would use it...
> And it also has the downside of looking like a function call, but
> having different rules for what can be put inside it:
> function foo();
> closure(foo); // fine.
> special_closure(foo); // syntax error, undefined constant foo.