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!
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.
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...
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".
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.
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?")
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.
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 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.
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!
39 comments
[ 4.2 ms ] story [ 85.9 ms ] threadAnd 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...
Normalize closing stuff like this without further discussion as far as I'm concerned
"Don't do that." </resolved>
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.
The Stackoverflow post is about detecting the end of a render cycle in useEffect.
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
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.
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.
https://www.ifixit.com/News/74736/warranty-void-stickers-are...
https://en.wikipedia.org/wiki/Undefined_behavior