On Thu, Jun 13, 2019 at 10:49 PM Mark Clements (HappyDog) <
phpn...@kennel17.co.uk> wrote:
> Hi there,
>
> I've been reading with interest about the new FFI class that has been
> introduced in PHP 7.4 [1].
>
> However, I was surprised to see that the class includes bivalent methods,
> that is to say methods that can be called both statically and
> non-statically. For example, new() [2], which can be called as:
>
>FFI::new(...)
>
> or non-statically:
>
> $objFFI->new(...)
>
> (Note that the latter is not simply a short-cut to the former, as it
> accesses the instance properties.)
>
> As you can see, this is a very useful design pattern, but it is one that is
> currently disallowed in userland code:
>
> * If you declare a method as static, you can call it in both ways, but in
> neither case can you access the instance properties or any other instance
> functionality ($this is undefined).
> * If you don't declare the method as static, and call it statically, you
> get
> a deprecation notice:
>
>Deprecated: Non-static method MyClass::MyMethod() should not be called
>statically in file.php on line X
>
> This FFI class is therefore introducing an inconsistency in the language.
> My understanding is that the general direction of travel is to try and
> remove language inconsistencies, where possible, so introducing new ones
> seems like something that should be strongly avoided where possible.
>
> My preference would be to resolve this inconsistency by un-deprecating the
> uses of non-static methods in a static context. As per the example in the
> FFI class, there are clearly use-cases where both methods of calling a
> function are desirable. We have a number of such examples in our code
> (e.g.
> we have a GetMonthName() function in our date class, which can either
> operate on an instantiated object or be called statically with any
> date-like
> argument). These functions currently detect the context and only access
> $this when called non-statically. Correctly implemented, this type of
> overloading leads to very clean interfaces (though I understand the risks
> that inexperienced programmers might face).
>
We won't do this. In fact, this functionality is already completely removed
on master.
Alternatively, the FFI class should implement two different methods for the
> different contexts.
>
Another possibility would be to make most of the current static methods on
the FFI class into free functions. I.e. FFI\memcpy() rather than
FFI::memcpy() and only keep the things that actually interact with an FFI
context on the FFI class (which might be better named FFI\Context or
similar). I think this would be semantically cleanest, but also a pretty
significant change.
Nikita
