Re: Re: [Concept] Extension methods

On Wed, Aug 10, 2022, at 5:23 PM, Deleu wrote: > On Wed, Aug 10, 2022, 11:30 PM Rowan Tommins <rowan.collins@gmail.com> > wrote: > >> >> To be honest, I put them in that order more for "purity" reasons: if they >> come before __call, they can change the existing behaviour of the class, by >> defining an extension method with the same name as a "virtual" method >> implemented with __call. That then becomes a very different feature. >> > > I would argue in favor of extension having precedence over __call because > 1) classes with __call wouldn't be able to be extended and > 2) extensions > could actually "fix" the ~ab~use of some use of __call. I suppose this > would allow me to write an Extension that mimics the exact behavior of > __call and actually avoid __call from being hit while still keeping the > same behavior of the class. Possibly very dumb idea, but I'll throw it out anyway: Would it be OK if extension methods came *before* normal methods? Would that allow a compile time translation of this: use extension Foo:bar; $collection->bar($b); to this: Foo::bar($collection, $b); Since the extension would only have public access anyway (modulo messing around with rebinding and reflection, of course), it's logically equivalent to just a static method like that. That could allow the existing autoload logic to work (if extensions compile into just classes), and no runtime overhead because it's "Just" a static method call; if it's missing, oh well, it just fails like a static method call. A side effect of that is indeed that you could override an object's method externally, in effect, at the loss of internal access. I... could probably make a solid argument for that being very good or very bad, depending on my mood. (I'm at the moment lukewarm on the idea overall, and I still believe pipes are the superior solution, but if we do it then it should be done well.) --Larry Garfield