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:
> >>> Hello internals,
> >>>
> >>> I've been thinking about having an "internal" attribute that will emit
> >>> a warning if called from outside it's left-most namespace.
> >>>
> >>> It might look something like this:
> >>>
> >>> namespace MyCompany\PackageA {
> >>> #[\Internal] function doStuff() {}
> >>> }
> >>>
> >>> namespace OtherCompany\PackageB {
> >>> \MyCompany\PackageA\doStuff(); // warning emitted
> >>> }
> >>>
> >>> namespace MyCompany\PackageB {
> >>> \MyCompany\PackageB\doStuff(); // left-most part of namespace
> >>> matches, no warning
> >>> }
> >>>
> >>> This would allow for library maintainers to mark internal constructs
> >>> as such and provide users with feedback that they are using code that
> >>> may be changed without any notice.
> >>>
> >>> Any thoughts?
> >> I do like the idea in general of being able to mark certain things as
> >> internal to a certain namespace.
> >>
> >> My question is more in the direction of: If we are not enforcing
> >> breaking the code but merely emit a warning then that is IMO not
> >> something that we need to implement on the language level. People will
> >> still be able to use the internal method and just ignore the warning.
> >
> > 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.
>
> 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 |
> +---------------------------------------------------------------------+
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.
Robert Landers
Software Engineer
Utrecht NL
