Hey Robert. Am 19.05.24 um 09:38 schrieb Robert Landers:
On Sat, May 18, 2024 at 9:11 PM Andreas Heigl <andr...@heigl.org> wrote:Am 18.05.24 um 19:46 schrieb Robert Landers:On Sat, May 18, 2024 at 7:38 PM Andreas Heigl <andr...@heigl.org> wrote:Hey all. Am 18.05.24 um 16:00 schrieb Robert Landers:
[snip]
I guess that depends on what you mean by "break the code." Many people turn warnings into exceptions, and for those people this will effectively break their code. Some people may choose to ignore it one way or another, but that would be up to them. The idea isn't to break people's code though, it's to provide a way to mark very-malleable APIs in libraries. Maybe, "Internal" is a bad name for this, but it's the most logical.The trouble I see is that there are two kind of people: Those that care about such things and those that don't. Those that care about such things will already find these issues during static analysis. Those that don't care will not turn errors into exceptions but instead have error-reporting set to 0 That's why I am hesitant in adding this to the engine but instead would love to see this as part of userland maintained static analyzers.
[snip]
Hey Andreas, I don't think this is a useful way to look at it. Otherwise, what is the point of making any error or warning? Static analysis is useful, but there's a lot of things it misses, especially when dynamic calls start happening.
Probably the most interesting question is about our and the users expectation when declaring respectively using an internal entity.
Is it's use something that should just pop up in the logs? And if so: What does it mean? Is using an internal entity outside it's expected usage actually an error? After all an error should be used when the application hits an issue preventing one or more functionalities from properly functioning. We can not really say that is happening just because someone uses a function in a place we do not expect it to be used. It might still work.
But from the point of view of the person declaring that internal entity muich more should happen. The code shouldn't work AT ALL any more. Someone is using my code in a way that I did not intend it to be used, so the whole application should break.
But we can not assert that.So by having a look at the expectations of the different parties we can calibrate our intentions and then see how we can provide the best solution.
And to me in that case the best solution would not be to enforce this on the language level but to leave it to static analysis. Because I know how inventive people can get to use things in ways they are not supposed to be used. Search for `composer unfinalize`...
Cheers
Andreas
--
,,,
(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.asc
Description: OpenPGP digital signature
