Re: [PHP-DEV] [RFC]

This is only part of a thread. view whole thread
  108497
February 11, 2020 19:20 Danack@basereality.com (Dan Ackroyd)
On Tue, 11 Feb 2020 at 19:08, Dik Takken takken@freedom.nl> wrote:

> $($obj->Fot); > 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. Also, just in general using something that has the same syntax as current PHP code, but a different meaning, sounds like a bad idea.
> 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. 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. Although avoiding new syntax is good in general, if what can go inside it is different, then I think it requires a new syntax. cheers Dan Ack
  108499
February 11, 2020 20:11 d.h.j.takken@freedom.nl (Dik Takken)
On 11-02-2020 20:20, Dan Ackroyd wrote:
> On Tue, 11 Feb 2020 at 19:08, Dik Takken takken@freedom.nl> wrote: > >> $($obj->Fot); >> 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.
That is a downside indeed. Regards, Dik Takken