Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove 'final' keyword #26

Open
TerraTech opened this issue Jul 4, 2018 · 2 comments
Open

Remove 'final' keyword #26

TerraTech opened this issue Jul 4, 2018 · 2 comments

Comments

@TerraTech
Copy link

Would you be open to removing the 'final' keyword so that the class can be easily extended?

I was looking at extending this in one of my utility libraries where I could canonicalize and return the first 3 directories in the path while having access to all the other Path methods. As an aside, maybe adding a first class method that performs this in a canonical way. This is helpful when you have a cross sectional tree setup with different projects where you need to autoload the right '.../vendor/autoload.php', from wherever you are in tree.

e.g.:
/devel/projects/A/www/vendor
/devel/projects/B/www/vendor

so if I write a quick test jig in: /devel/projects/B/www/entities/test.php

I can quickly require_once the correct:

require_once(Path::join(Path::first(__DIR__, 4), Path::canonicalize('vendor/autoload.php')));

I could inject it, but I'd have to write bounce helpers for all static methods I was going to use.

Personally, I don't believe any general purpose library should use final, because the point of a library is the ability to extend them to add enhanced functionality or change certain behaviors if need be to solve/integrate a task at hand. My general rule is that only class/objects, that are to be fully concrete should use the 'final' keyword, or where a class has certain security implications that it needs to be locked down to prevent behavioral modifications. I'm open to contrary viewpoints though.

Thank you for your consideration.

@GrahamCampbell
Copy link

Being final is fine. If you need to extend, you can instead, compose. This is a much safer way to do things.

@c33s
Copy link

c33s commented Jan 21, 2021

Being final is fine. If you need to extend, you can instead, compose. This is a much safer way to do things.

in this case this is simply unhandy, the methods are separated and static. not that important to make the class final. it takes much more effort to compose a class. it requires to use magic methods or to duplicate all method signatures in the class to pipe all the other 20 or more methods to the original class only to add one or two methods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants