Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98001
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.65 as permitted sender)
MIME-Version: 1.0
Sender: giovanni.g@gmail.com
In-Reply-To: <CAOv67gtRoM9_Wqe4JEjCT_rQm=gbZHrQUuh+g0JgEDeyEW0G=Q@mail.gmail.com>
References: <503add40-506e-f8e9-8a4f-59cecc429018@mabe.berlin> <CAOv67gtRoM9_Wqe4JEjCT_rQm=gbZHrQUuh+g0JgEDeyEW0G=Q@mail.gmail.com>
Date: Sat, 28 Jan 2017 11:51:03 +0100
Message-ID: <CAML1Pf6+rQYeRKJdH0Y0Gp2Phg9mEeaXtc7RcM30q4DrjcmZDA@mail.gmail.com>
To: Wes <netmo.php@gmail.com>
Cc: Marc Bennewitz <dev@mabe.berlin>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11479100ddf2bf0547255bb4
Subject: Re: [PHP-DEV] Allow "static" type
From: giovanni@giacobbi.net (Giovanni Giacobbi)

--001a11479100ddf2bf0547255bb4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 28 January 2017 at 10:18, Wes <netmo.php@gmail.com> wrote:

> Hi=E2=80=8B, static could be definitely a valid return type, but I don't =
see this
> happening for parameters, for the same reasons this is disallowed:
>
> class A{ function bar(A $a){} }
> class B extends A{ function bar(B $b){} } // must be contravariant, but B
> is covariant to A
>
>
That's not completely true, the contravariance rule exists to defend the
polymorphism and overriding, BUT this is a static scope so it is *almost*
like an overloading, I.E. B will have *another* method bar which is
different from A's, the only difference is that B should also inherit
original's A::bar but it does not, it's like A::bar(A) is not inherited.

Before anyone say it, I know you can use the $a::bar() syntax to invoke
static methods, but I consider that a shorthand of A::bar() and what people
should *always* use unless they have complete control over the code and
invocation stacks.

I did in fact hit a use for this feature a long time ago where I wanted to
have a static method which is able to operate (in my case delete from
database) an instance of an object, and I solved it WAY before the
introduction of all this syntactic madness I've been witnessing recently,
which is:

  public static function delete(self $object) {
    $class =3D get_called_class();
    $baseclass =3D get_class($object);
    assert('($class =3D=3D $baseclass) || is_subclass_of($class, $baseclass=
)');
    // do whatever you need to do
  }

The reason is that I always want the caller to be aware of what he is doing
and never use the "standard" method on a subclass which actually redefines
it.

Even though I like the proposal and I would personally use it, I'm against
it because I think PHP has been getting a lot of "features" which only safe
a few keystrokes in very edge cases but complicate the language and steep
the learning curve, which was the only real strong point of PHP, its
simplicity.

I think the latter thought is a bit offtopic, one day I will start a thread
to start philosophizing on the direction PHP had taken the past years (good
old times when the strict type hinting was rejected because it made it too
complicated for newcomers, lol).

Cheers

--=20
Giovanni Giacobbi

--001a11479100ddf2bf0547255bb4--