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.

So when we not break the flow this is something that static analysers can do as well. They will immediately spot when an internal function is used outside the expected namespace and can then raise the appropriate flags so that the problem can be fixed.

That then also raises the question for me whether the attribute actually needs to be provided by the language itself or whether that is something that can be added by the static analyzers or - if we want one attribute for all namespaces - perhaps even by the FIG. THough that would probably be a case where the FIG would not provide an interface but an actual class implementation.

Regarding the attribute itself I would declare the namespace it is supposed to be internal to in the attribute itself.

So something like

namespace MyCompany\PackageA\SubpackageA {
    #[Internal(MyCompany\PackageA)] function doStuff(){}
}

might be used to define a function that can be used in all code of PackageA while still being declared in the Subpackage.

I would like that more than relative "paths" like

namespace MyCompany\PackageA\SubpackageA {
    #[Internal(..)] function doStuff(){}
}

or something like that.

Yes, this opens the possibility to even declare functions internal to packages outside the actual namespace and we might need something to make sure to disallow that so that the namespace the part is internal to can only be part of the namespace it is defined in.

My 0.02 €

Cheers

Andreas



Robert Landers
Software Engineer
Utrecht NL

--
                                                              ,,,
                                                             (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                          |
+---------------------------------------------------------------------+

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to