Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106835
MIME-Version: 1.0
References: <C228D1E3-C20A-42B8-8006-01E34FFFB5A6@cschneid.com>
 <CA+kxMuRBRNkPKK+rf-vMFOcOEr3a4a9+VJ3hRrtPF_4asbmg4g@mail.gmail.com> <F982CE0F-B1E1-4E66-A8A0-AAFA77FE0F12@cschneid.com>
In-Reply-To: <F982CE0F-B1E1-4E66-A8A0-AAFA77FE0F12@cschneid.com>
Date: Mon, 2 Sep 2019 20:03:51 +0200
Message-ID: <CAH0Uv3HpPksJDmqHe1nXo7fmZsyu7qMRgQeXz6aLdn37kDSZgQ@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: Dan Ackroyd <danack@basereality.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Mixed mode methods
From: andreas@dqxtech.net (Andreas Hennings)

In my experience, things that have different roles or behavior should
be differently named.

I have seen a lot of functions with dynamic return types based on a
mode set in the parameter (e.g. the return type could be string,
string[] or string[][] depending on whether some parameter is NULL or
not). In all cases, the confusion and ambiguity caused by this was far
greater than the supposed / perceived convenience.
Often enough, the increased complexity of control flow branches inside
the function would lead to bugs, which could remain undiscovered for
years.

Maybe the only benefits were to not pollute the global namespace as
much, and to give access to the same static variables for caching.
None of these benefits apply in an object-oriented scenario.

A method body which has to handle and distinguish static and
non-static calls would easily suffer from the same problems.

On Mon, 2 Sep 2019 at 18:03, Christian Schneider <cschneid@cschneid.com> wrote:
>
> Am 02.09.2019 um 17:01 schrieb Dan Ackroyd <danack@basereality.com>:
> > Also(, without checking to see if it's feasible,) to me a less
> > surprising approach would be to allow static and instance methods to
> > be declared separately with the same method name.

This would at least solve the problem of added complexity in the method body.
Still, as Dan Ackroyd points out, there needs to be a clear benefit.


> I was considering this approach but that is a special case of Ad hoc polymorphism (https://en.wikipedia.org/wiki/Ad_hoc_polymorphism).
> And that's a path I don't want to go down, I don't think that's a good fit for PHP.
> It felt more natural to model it similarly to nullable return types.

The value of parameter-based polymorphism is for cases where the
calling code wants to handle all parameter types in one call, whereas
the callee has different implementations for different parameter
types.

This is not the case here: The calling code does always know whether a
call should be static or not, so it can choose the applicable method
name.


On Mon, 2 Sep 2019 at 18:03, Christian Schneider <cschneid@cschneid.com> wrote:
>
> Am 02.09.2019 um 17:01 schrieb Dan Ackroyd <danack@basereality.com>:
> > Also(, without checking to see if it's feasible,) to me a less
> > surprising approach would be to allow static and instance methods to
> > be declared separately with the same method name.
> >
> > class Foo {
> >    static function loadXml() {
> >        echo "I am static method\n";
> >    }
> >
> >    function loadXml() {
> >        echo "I am instance method\n";
> >    }
> > }
>
> I was considering this approach but that is a special case of Ad hoc polymorphism (https://en.wikipedia.org/wiki/Ad_hoc_polymorphism).
> And that's a path I don't want to go down, I don't think that's a good fit for PHP.
> It felt more natural to model it similarly to nullable return types.
>
> - Chris
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>