Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79259
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.49 as permitted sender)
Message-ID: <54781777.6090208@gmail.com>
Date: Thu, 27 Nov 2014 22:34:31 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>, 
 Rowan Collins <rowan.collins@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <CAFp73XvRNoDF5N1-H4+YBSB3G2_OBAM3+x6Tu3beT5-H9O+deg@mail.gmail.com> <547723A8.8090008@gmail.com> <CAFp73Xvh1UrMpH9Kp9AVEinqEX72Qo2Su+TPgc-VVcRrPh4q1w@mail.gmail.com>
In-Reply-To: <CAFp73Xvh1UrMpH9Kp9AVEinqEX72Qo2Su+TPgc-VVcRrPh4q1w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Abstract final classes
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> By forgetting "static" in any of your declared methods, you get no parse
> error and gives you 2 possibilities:
> - With E_STRICT enabled: Fatal error when non-static method is being
> statically called. You'll only get this at runtime, leading to potentially
> error prone. Now the testability come that with this addiction, you get a
> fatal error, which is easily fixable at compile time, not runtime.

I don't see how it matters for testability - sure, if you don't test
your functions, you don't see the errors, but that's just best practice.
Also, since PHP is not a compiled language, practical difference between
"compile time" and "runtime" does not really exist.

> - With E_STRICT disabled: You get a warning on php log and everything works
> (which is a huge wtf mode).

Not everything, your functions still do not. If you write a function and
put it in production without ever trying to run it even once, that's
something that needs to be fixed (and you could as well have made a typo
in a function name or written whille() - there are a lot of errors that
one can make and PHP does not catch, especially if you never run your
code). Otherwise, the error is immediately obvious.

> My end goal is to add class visibility to PHP. Unfortunately, I was forced

I'm not sure how it is related, but if it's not directly connected then
since that RFC does not exist AFAIK I don't think it can be an argument
for this one. If it is directly connected then maybe it could wait for
that RFC but then connection needs to be explained.

> No, because conceptually, a static something means that subsequent calls
> always return same value. A static class means a singleton, not what this

I'm not sure where it comes from - static function definitely does not
return same value on each call. Neither do static variables (which are
just class variables, but not immutable) or static closures (which are
just unbound closures). The only case where it is kind of true is static
variable in function, if you replace "value" by "variable", but this is
only because the syntax was borrowed from C. So static in PHP means a
lot of thing but the general gist is "not subject to current scope".
Where the "static class means a singleton" came from? Could you explain?

> You are correct. Methods cannot be declared abstract if you have an
> "abstract final". They must also be static. I added these checks together

To me, it just feels a bit unnatural. So you have abstract class, which
usually has abstract methods. Then you have "abstract final" class which
can not have abstract methods, but instead should have "static" methods.
This just sounds a bit weird to me - adding "final" to description of
the class completely changes all the rules in very unexpected direction.

-- 
Stas Malyshev
smalyshev@gmail.com