You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
The text was updated successfully, but these errors were encountered: