Hey there On 03.12.22 23:55, Karoly Negyesi wrote:
They refuse to compromise even on documentation issues. I am totally helpless. Not sure what could be done?
When people design their systems and use final, private or readonly, they have a reason for that. They have a plan on how their library should be used and also how their library should not be used.That is the API that is exposed via public methods that is described in the documentation.
When *your* code can only make use of a library by tweaking these constraints, you are using the library in a way that is not intended by the authors.
There can be two reasons to that: Either you know exactly what you are doing and you are willing to risk that the way you are using said library might break with every patch version as the internal workings might change.
HERE BE DRAGONS: I sometimes actually need to do that (even with a library I wrote myself) but instead of using reflection I then tend to use monkey-patching in that case and actually rewrite the code of the lib on installation. That way the execution is faster as I do not rely on reflection but can access a public property directly.
Or - and that is most of the time the case - you are using the library wrong or even using the wrong library.
And as you already contacted the authors and they declined your request to change their API, the chances are high, that you are using their Library in an unintended way.
In that case you should reconsider what you are doing. Am I using the right library? Why could I be using the library wrongly? How can I change my code to use the provided API of the library?
In the end it always boils down to: Check whether your usecase is what the library is intended to solve. And if there is no way around rewriting upstream code: You are on your own! You can not rely upon anything. Not even language features. You are not using upstream code, you are abusing it.
My 0.02 € Cheers Andreas
On Sat, Dec 3, 2022 at 2:48 PM Marco Pivetta <ocram...@gmail.com> wrote:Talk to the designers then: bringing your own political issues up to the programming language/tooling only makes it worse long-term, for everyone 😛 On Sat, 3 Dec 2022, 23:45 Karoly Negyesi, <kar...@negyesi.net> wrote:I do not have the luxury of designing my own system. I am forced to use upstream. I can't help it and given the history of private usage and the refusal on relaxing them I do not see this improving with the readonly. At all. On Sat, Dec 3, 2022 at 2:42 PM Marco Pivetta <ocram...@gmail.com> wrote:Terrible idea: reflection is mostly introspection tooling, and doesn't really bend the rules of the type system, other than crossing scope (it "sees" more). Please consider designing your system to consider the constraints of `readonly` properties, or design the constraints to fit your system instead. Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/ On Sat, 3 Dec 2022 at 23:39, Karoly Negyesi <kar...@negyesi.net> wrote:Hello, If push comes to shove, private properties can be changed with reflection. Readonly properties can't. Please add a readonly toggle to reflection. Thanks Karoly Negyesi
-- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +---------------------------------------------------------------------+
OpenPGP_signature
Description: OpenPGP digital signature