41 ms·
Not a Javascript expert (and no knowledge of how FB work), so one question: Why, just why?
by shantnutiwari 5y ago
Not a Javascript expert (and no knowledge of how FB work), so one question: Why, just why?
- bpodgursky 5y agoYou can't make package contents actually private so you have to discourage developers from depending on them in other ways.
- CodeMage 5y agoOkay, but why re-export it like this, then?
- bradly 5y agoThat makes sense, but threatening people’s jobs in a public package definitely rubs me the wrong way.
- ac2u 5y agoI gathered it as toungue-in-cheek
- bradly 5y agoOh I did as well, but junior developers, non-native English speakers, and under-represented engineers may have a harder time understanding the sarcasm or the believe the risk-of-ruin if they are misunderstanding the message is too high. Many of us are very privileged with the tech job market, that isn’t the case for everyone.
- DoctorDabadedoo 5y agoConsidering this comes from facebook, I hold no expectations regarding the morality of their actions. This is par for the course (would be stretch, but hey it's facebook).
- eminence32 5y agoIt's not a threat that sense. But it's eye-catching language that's supposed to make people take the "do not use" warning seriously.
- Brian_K_White 5y agoDid it encourage or discourage you from unsafe tight coupling? What do you mean threatening? Are you 5 years old and scared of words and also unable to interpret hyperbole? Perbaps you can guess from my comment here that something rubs me the wrong way too. Are you obligated to care about that? If I tried to suggest that you inject at least one "this wiill kill you cat" in your free public works because the dry lack of life rubs me the wrong way, what would be your response?
- bradly 5y ago> Are you 5 years old and scared of words This is not the way we communicate on Hacker News and I will not validate it with a response. Refer to the guidelines if this is unclear.
- SAI_Peregrinus 5y agoThe better way is to actually change such undocumented stuff unpredictably and automatically every release. Write a script to randomize the structure layout. Append random text to names. Don't document any of that, and don't keep the scripts to do so in the same repo. "This might change or break at any time" isn't nearly as good a deterrent as "This will change every release. Don't use it directly, use the public interface at <insert location>".