On Nov 27, 2014, at 10:34 PM, Stanislav Malyshev wrote:
>> 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 ab
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 testabili
Ok... so if I update the RFC to be "static class", does that make everybody
happy?
I mainly wanna get this forward thinking trend... =)
On Thu, Nov 27, 2014 at 10:49 AM, Rowan Collins
wrote:
> guilhermebla...@gmail.com wrote on 27/11/2014 15:34:
>
>> > This is true of classes intended to be stat
guilhermebla...@gmail.com wrote on 27/11/2014 15:34:
> 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 complete
> 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 al
guilhermebla...@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 __const
> 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 s
guilhermebla...@gmail.com wrote on 27/11/2014 03:47:
I worked on an implementation of a somehow controversial concept that
exists in hack and C#: abstract final classes.
https://wiki.php.net/rfc/abstract_final_class
The explanation of what exactly has been implemented could perhaps be
expande
On Thu, Nov 27, 2014 at 1:43 PM, Rowan Collins
wrote:
> Lazare Inepologlou wrote on 27/11/2014 10:35:
>
> 2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com <
>> guilhermebla...@gmail.com>:
>>
>> Hi,
>>>
>>> I worked on an implementation of a somehow controversial concept that
>>> exists in ha
Lazare Inepologlou wrote on 27/11/2014 10:35:
2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com <
guilhermebla...@gmail.com>:
Hi,
I worked on an implementation of a somehow controversial concept that
exists in hack and C#: abstract final classes.
https://wiki.php.net/rfc/abstract_final_clas
Hi,
2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com <
guilhermebla...@gmail.com>:
> Hi,
>
> I worked on an implementation of a somehow controversial concept that
> exists in hack and C#: abstract final classes.
>
> https://wiki.php.net/rfc/abstract_final_class
>
>
The example is a little bi
2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com <
guilhermebla...@gmail.com>:
> Hi,
>
> I worked on an implementation of a somehow controversial concept that
> exists in hack and C#: abstract final classes.
>
> https://wiki.php.net/rfc/abstract_final_class
>
> My motivation is to further expan
Hi!
> I worked on an implementation of a somehow controversial concept that
> exists in hack and C#: abstract final classes.
>
> https://wiki.php.net/rfc/abstract_final_class
In the RFC, I think one phrase needs clarification:
Currently, PHP developers' only resource is to create a final class
Except for the H1 on the RFC (needs to be updated), I can really see a lot
of cases where I needed this: badly.
On Nov 27, 2014 4:48 AM, "guilhermebla...@gmail.com" <
guilhermebla...@gmail.com> wrote:
> Hi,
>
> I worked on an implementation of a somehow controversial concept that
> exists in hack
14 matches
Mail list logo
