php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #65103 consider the final keyword depracation
Submitted: 2013-06-23 09:16 UTC Modified: 2013-06-25 07:45 UTC
From: knight at kopernet dot org Assigned:
Status: Wont fix Package: Class/Object related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2013-06-23 09:16 UTC] knight at kopernet dot org
Description:
------------
The final keyword is widely recognized among many programmers that adopted OOP paradigim esp. comming from or knowing Java.
I find it very problematic though.
Without a real compilation stage using the final keyword in the type hints does not make sure that all execution paths in the calling code passes an object of the expected type. This is completely different from Java which actually makes sure the correctness of the passed arguments.
Also when it comes to writing unit tests - there's no way to override a final class and test code that makes use or depends on such an object.

Please consider deprecating, removing the final keyword or release the imposed restriction.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-25 04:36 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2013-06-25 04:36 UTC] laruence@php.net
I think Final is very useful in the following case:

like I did in Yaf, I got a Yaf class, there are some key resource need to be 
initialized. if these resource didn't intialized, then maybe segfault later.

so, I defined a constructor. and do such initialization. but user can extends my 
Yaf class, and they also might define there own constructor, and doesn't call the 
parent::construct... 

so I make the Yaf::construct final.... every is fine now.
 [2013-06-25 07:45 UTC] ab@php.net
-Status: Feedback +Status: Wont fix
 [2013-06-25 07:45 UTC] ab@php.net
@knight at kopernet dot org

IMHO that should be either a request to implement something like Reflection 
makeInheritable() . The final keyword has its uses and PHP isn't Java. If you're 
really in the mood, please consider writing your thoughts about what should be 
done as improvement at this place, and discussing it on the internals list. Such a 
request is rather useless without discussing all possible pro and contra.
 [2013-06-25 07:58 UTC] knight at kopernet dot org
But the implementation is sealed. The only way to override the construction is to use a factory method e.g. call your constructor and proceed with remaining initialization in the factory method.
My initialization in the extended class can be as critical as yours yet I cannot do anything to prevent someone creating an object of my new type with only your(e.g. base) constructor called.
On the other hand if someone creates an object and forgets to call your constructor and it's so obvious as you say it segfaults than the programmer gets feedback immediately so I don't get why you insist on preventing it.
But your point is very good. I've seen that hundred times: someone tries to extend a framework component without truly understanding its lifecycle. A sealed constructor is a good way to make sure it is used correctly. Better yet if the constructor is protected so that only the factory method can be used to create the object. That's however imposes the need to adopt the usage of factory method throughout your codebase.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu May 13 17:01:24 2021 UTC