4 ms·

Here it seems "INTERNALS" is the "why". If it's not a public API then of course it could change or disappear without warning between releases (including minor r

Here it seems "INTERNALS" is the "why". If it's not a public API then of course it could change or disappear without warning between releases (including minor releases).

verdverm 5y ago
Go handles this by not allowing 3rd party to import a package path with internal/ in it. Only the current module can
- MaulingMonkey 5y ago
  Ancient vanilla JS can accomplish similar by using wrapper functions. var React = (function(){ var React = {}; var __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED = {}; ...code extending/using React etc... return React; })(); // accessible: React.whatever // inaccessible: __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED However, there's always caveats where language level access controls don't let you quite express the access restriction you want. Perhaps you want to expose something to other official modules from the same constillation of libraries, for example (meaning you wouldn't be able to use Go's "internal"), without comitting to supporting the semver contract for any other arbitrary user of your API (meaning you might resort to similarly scary names.)
  - ______-_-______ 5y ago
    iirc, react-dom (a separate package) needs to access that property as well, which is why it's exposed in the first place
  - udbhavs 5y ago
    Private properties in JS classes are syntactic sugar that compile to variable definitions like this in the object's scope
- mdoms 5y ago
  Most sane languages have visibility modifiers. This link refers to Javascript so...
  - verdverm 5y ago
    Go did that with casing, so you can tell visibility without lookup or needing to think. The internal/ is a package level restriction, so somewhat orthogonal in that they are for different levels
- drdaeman 5y ago
  Which is awful, because I've seen a number of FLOSS projects that have perfectly good reusable code in their internal/ subdirectories. And I mean code by no means unique or specific to those projects. And whoever says something about instability or APIs being subject to change without notice - they're wrong because those are Go git repos and one can always pin to an old tag or even a commit SHA. If something is unusable (too specific, too fragile, too flaky), no one would use that anyway. A warning is fine and even welcomed, but a block is a slap in the face.

Here it seems "INTERNALS" is the "why". If it's not a public API then of course it could change or disappear without warning between releases (including minor releases).

verdverm 5y ago

Go handles this by not allowing 3rd party to import a package path with internal/ in it. Only the current module can

MaulingMonkey 5y ago
Ancient vanilla JS can accomplish similar by using wrapper functions. var React = (function(){ var React = {}; var __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED = {}; ...code extending/using React etc... return React; })(); // accessible: React.whatever // inaccessible: __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED However, there's always caveats where language level access controls don't let you quite express the access restriction you want. Perhaps you want to expose something to other official modules from the same constillation of libraries, for example (meaning you wouldn't be able to use Go's "internal"), without comitting to supporting the semver contract for any other arbitrary user of your API (meaning you might resort to similarly scary names.)
- ______-_-______ 5y ago
  iirc, react-dom (a separate package) needs to access that property as well, which is why it's exposed in the first place
- udbhavs 5y ago
  Private properties in JS classes are syntactic sugar that compile to variable definitions like this in the object's scope
mdoms 5y ago
Most sane languages have visibility modifiers. This link refers to Javascript so...
- verdverm 5y ago
  Go did that with casing, so you can tell visibility without lookup or needing to think. The internal/ is a package level restriction, so somewhat orthogonal in that they are for different levels
drdaeman 5y ago
Which is awful, because I've seen a number of FLOSS projects that have perfectly good reusable code in their internal/ subdirectories. And I mean code by no means unique or specific to those projects. And whoever says something about instability or APIs being subject to change without notice - they're wrong because those are Go git repos and one can always pin to an old tag or even a commit SHA. If something is unusable (too specific, too fragile, too flaky), no one would use that anyway. A warning is fine and even welcomed, but a block is a slap in the face.