Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED? | Hacker News Reader

Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED?

github.com

93 pointskeepamovin37 comments

I'm imagining increasingly catastrophic variable names ("__SECRET_INTERNALS_DO_NOT_USE_OR_YOUR_SOUL_WILL_BE_CONDEMNED_TO_HELL_FOR_ETERNITY") followed by increasingly comical workaround requests ("OK, yeah, so if I'm Buddhist, and we don't believe in hell, can I access this property?")

Easy. Like everything else in software another level of indirection can help.

You can threaten hell and experience it while maintaining code with functions & variables like

__SECRET_INTERNALS.IAM_A_BUDDHIST.IAM_WILLING_TO_VISIT_NARAKA_BY_USING_THIS.VARIABLE_FROM_HELL_1

__SECRET_INTERNALS.IAM_AN_ATHEIST.I_ACCEPT_THERE_IS_GOD.GOD_VARIABLE_1

Lol

Buddhism has a sophisticated landscape of hells :-)

Dante tried to backport that into Christianity.

Yes, just know that it is impermanent.

Echoes of Haskell's `accursedUnutterablePerformIO` https://hackage.haskell.org/package/bytestring-0.10.8.1/docs... :

  This \"function\" has a superficial similarity to 'unsafePerformIO' but
  it is in fact a malevolent agent of chaos. It unpicks the seams of reality
  (and the 'IO' monad) so that the normal rules no longer apply. It lulls you
  into thinking it is reasonable, but when you are not looking it stabs you
  in the back and aliases all of your mutable buffers. The carcass of many a
  seasoned Haskell programmer lie strewn at its feet.
  Do not talk about \"safe\"! You do not know what is safe!
  Yield not to its blasphemous call! Flee traveller! Flee or you will be
  corrupted and devoured!

Thank you I like when art and poetry mixes with programming

I suspect this is a reference to a famous privacy-related module in the facebook codebase circa 2010ish, which had a docstring something like "DO NOT TOUCH. YOU WILL BE FIRED". Could be a cultural holdover from when react was an internal facebook project.

It's just an over the top and funny way to label global variables that shouldn't actually be used for the sake of API stability. I've seen this in many different companies and code bases.

It is, it was then used regularly across project as a sign that touching this code is very dangerous and should not be done except by the experts of that codebase.

Fun nostalgia to see it out there :)

Note that I doubt anybody ever got fired for modifying these parts of the code. In particular, automatic refactors would have modified these (safely); and it’s a scary warning about negative consequences of messing up.

I’m a fan of irrevocable confirmation dialogs with scary and non-mistakable requirements like “type I HEREBY ABANDON THE FILE IMG0123.PNG AND WILL EAT SIX LIVE RATTLESNAKES IF IT EVER OCCURS TO ME THAT I MIGHT WANT IT BACK to continue”.

The number one source of both professional services revenue and production incidents at one of my previous companies were from users who would completely remove or invalidate anywhere between 600 and 60,000 records from our system EVEN AFTER typing:

reject sixty two thousand four hundred and six records

into a modal with paste disabled and a red background.

You can't fix stupid, even if they're paying customers.

Hahahahahaha. I use this naming scheme sometimes too. Also like "__IF_YOU_USE_THIS_YOU_ACCEPT_DEATH__X". If anybody will ever see it or you don't know, DO NOT USE IT. In most languages, you have "private" but sometimes you have to negotiate with your fellow programmers!

> "In most languages, you have "private""

And then you get "I hacked the headers to expose your private variable, and now my program is broken, help!"

Back when I did a lot more Objective-C you'd have programmers that figure out your private APIs and custom craft invocations to it. Yay.

It feels like getting programmers to code to API contracts, instead of observed behavior, is just one of the toughest things out there...

> "I hacked the headers to expose your private variable, and now my program is broken, help!"

Normalize closing stuff like this without further discussion as far as I'm concerned

"Don't do that." </resolved>

Haha, I have certainly done this in the past. I used to get frustrated no end when access to some internal function or variable was exactly what was needed to make things actually do what I needed. The alternative being write the entire thing from scratch.

I have learned from this experience to try to make my own stuff safe to extend without needing to access genuinely internal stuff, but it's a lot of work to achieve that level of flexibility. I can see why people generally don't bother.

Even if it's usually a terrible idea, I quite like how formal objective-c and swift make doing this with extensions/categories. Subclassing would probably be easier to read, but extensions sure beat the hell out of whatever hacks someone would come up with to add a method to the String class.

I've been told that Windows intentionally destabilizes the syscall interface so you have to use the official dll interface and can't just make kernel calls yourself. I wonder if there isn't something to that.

Even in languages with `private` you'd better label it correctly, otherwise some programmer will inevitably make it `public`...

naturally. your private body parts also have different names than your public ones. names that you would not mention in public either. stripping the private label is like well, stripping...

Or the worst is "here is a custom build of clang which ignores all private variables so you don't have to worry about it".

Another way to look at it is that using this object will result in undefined behavior up to and including making demon's fly out of your nose.

https://en.wikipedia.org/wiki/Undefined_behavior

Is it safe to tear off a paper tape with WARRANTY VOID IF BROKEN written on it?

Yes, depending on where you are located. Those aren't enforceable in a lot of places:

https://www.ifixit.com/News/74736/warranty-void-stickers-are...

At least in the US, these have no legal basis.

On a sidenote, I love how this post has been banished from the front page and yet continues to acquire upvotes

Previous discussion https://news.ycombinator.com/item?id=30194345

reminds me: https://www.youtube.com/watch?v=spLA3bpAfyI

I mean obviously, don't use it. But as usual, devil's advocate:

    The behavior can change on any release

The most popular React framework, NextJS, vendors a specific, unreleased version of React and their documentation recommends the use of APIs that have never been in a stable release. That's apparently accepted everywhere. This particular variable couldn't be any worse.

A lot of the thingies you can access from it are only set in development builds of React, so you will just get “null” all the time in production. If you spend like 8 hours building around it without knowing that, you’ll be pretty sad how it breaks when you finally test in an optimized production build.

If NextJS vendors that React version and then recommends using those APIs, then it can be argued to becomes part of the public interface. On the other hand, the scary-named property is clearly meant to discourage that in a language where locking things down is otherwise quite difficult.

Everything about this is so wrong. From the "Is this ridiculously clearly named and comically scary name safe to use?" to "Why don't you provide stable API for some internal state of React itself?"....

The latter is a legit question, for which the answer would be a variation of "it makes future development more difficult for the framework developers" and "please send a proposal for a stable API".

Tying internals to an external program would be a disaster. That’s why there are APIs…

I fully agree. That's why a stable API is needed. But there might be legitimate concerns to not expose such an API as it could impede development. For example, Java intentionally doesn't offer a stable API to extend the compiler. Therefore, Project Lombok has to adapt to each Java release as the OpenJDK project can and will change the compiler's internals at any time.

Maybe, but from what limited information he gives, his use-cases also seem insane.

The Stackoverflow post is about detecting the end of a render cycle in useEffect.

Reply on news.ycombinator.com