Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79234
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54773DD8.7030907@gmail.com>
References: <CAFp73XvRNoDF5N1-H4+YBSB3G2_OBAM3+x6Tu3beT5-H9O+deg@mail.gmail.com>
 <547723A8.8090008@gmail.com> <CAFp73Xvh1UrMpH9Kp9AVEinqEX72Qo2Su+TPgc-VVcRrPh4q1w@mail.gmail.com>
 <54773DD8.7030907@gmail.com>
Date: Thu, 27 Nov 2014 10:34:42 -0500
Message-ID: <CAFp73XtVLYnsxUkb7BupNu12vYorxnrAV_V4socf0UiNgH0mQg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1140751048b2c80508d8e30d
Subject: Re: [PHP-DEV] [RFC] Abstract final classes
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a1140751048b2c80508d8e30d
Content-Type: text/plain; charset=UTF-8

> This is true of classes intended to be static whether or not they are
final. Allowing a "static class" would allow you to
> enforce that all methods (and properties) must be static without banning
users from extending it (which is a completely
> orthogonal decision).

So if I still want to not allow anyone to extend it, I would then have a
final static class. Remember, I don't want people to change methods'
visibility.
How does that become different from final abstract? I know you answered
below... =)

> That's not how they're interpreted with regard to methods, unless I'm
missing something:
>
> - "abstract function" means a method which must be implemented by a
sub-class
> - "static function" means a method with no access to $this, operating
outside of any instance
>
> Taking those behaviours for class definitions leads to the interpretation
that seems natural to me:
>
> - "abstract class" means a class which must be extended before use, and
may contain abstract methods
> - "static class" would mean a class which can never be used to create an
instance, and can contain only static methods
>
> "final" is orthogonal to these, and means that a class cannot be
extended; under this interpretation, "abstract final" is a
> contradiction, but "static final" makes perfect sense.

The piece it's missing in "static" definition: there can only be one
instance of something.
I'd argue that declaring a class static is the same as declaring a
singleton. Multiple object instantiations over a static class would return
always same instance.
Now taking this into consideration, I'd modify your concepts to the
following:

- "abstract function" means a method which must be implemented by a
sub-class
- "static function" means a method with no access to $this, operating
outside of any instance. This means it's bound to class entry, which can
only have one possibility to be called: statically and given same
parameters it should return same output, unless normal flow controlled by a
static variable.

I'm more than happy to change "abstract" to "static" if it's the desire of
everybody. That would match C# implementation as defined here:
http://msdn.microsoft.com/en-us/library/79b3xss3.aspx Now it's funny that
C# also accepts "abstract final" with the same idea/concept of their
documentation of static classes. #weird

[]s,


On Thu, Nov 27, 2014 at 10:06 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> guilhermeblanco@gmail.com wrote on 27/11/2014 14:08:
>
>> > In the RFC, I think one phrase needs clarification:
>> >
>> > Currently, PHP developers' only resource is to create a final class with
>> > a private constructor, leading to untestable and error prone code.
>> >
>> > What is "error prone" in private __construct(); and how the RFC improves
>> > the testability of such class?
>>
>> The reason comes not to the construct method itself, but to other
>> implemented methods.
>> 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.
>> - With E_STRICT disabled: You get a warning on php log and everything
>> works (which is a huge wtf mode).
>>
>
> This is true of classes intended to be static whether or not they are
> final. Allowing a "static class" would allow you to enforce that all
> methods (and properties) must be static without banning users from
> extending it (which is a completely orthogonal decision).
>
>
>  > "Abstract final" is a strange way to name it. What you want is a
>> "static" class:
>>
>> > This has always been my feeling. To me, "abstract" means "must be
>> extended", and "final" means "can't be extended", so > combining the two
>> seems like a self-contradiction.
>> >
>> > The fact that abstract classes allow static methods to be called
>> without sub-classing always seems a bit odd to me - it's as > though only
>> the constructor is really abstract, not the whole class.
>> >
>> > A "static" class, however, whether "final" or not, is definitely
>> something I've wanted.
>>
>> > for the record I also brought up this argument (abstract and final being
>> > contradicting ideas) in the pull request comments(before this thread was
>> > created).
>>
>> No, because conceptually, a static something means that subsequent calls
>> always return same value. A static class means a singleton, not what this
>> patch proposal.
>> You have to remember:
>> - "abstract" means it cannot be instantiated directly
>> - "final" means it cannot be extended
>>
>
> That's not how they're interpreted with regard to methods, unless I'm
> missing something:
>
> - "abstract function" means a method which must be implemented by a
> sub-class
> - "static function" means a method with no access to $this, operating
> outside of any instance
>
> Taking those behaviours for class definitions leads to the interpretation
> that seems natural to me:
>
> - "abstract class" means a class which must be extended before use, and
> may contain abstract methods
> - "static class" would mean a class which can never be used to create an
> instance, and can contain only static methods
>
> "final" is orthogonal to these, and means that a class cannot be extended;
> under this interpretation, "abstract final" is a contradiction, but "static
> final" makes perfect sense.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--001a1140751048b2c80508d8e30d--