3 ms·

In this vein I wonder if it wouldn't be a bad choice to underscore the non-verified decode methods in token API's. Surely people would still abuse them but at l

In this vein I wonder if it wouldn't be a bad choice to underscore the non-verified decode methods in token API's. Surely people would still abuse them but at least there's an immediate visual warning if you choose not to read the docs, "Why is this method underscored but the other one not?"

hinkley 6y ago
It's still booby-trapping. I'm finding as I get older that a lot of programmers use their own mistakes to rationalize why they are the only ones who should be trusted with certain things. Well, of course I'm in charge. Last time Steve did something he pushed the big red button that shut down the whole server room. If I weren't in charge, then it would just be "Steve"s everywhere. Anarchy. Who put the red button there? Who thought having the big red button there might be a stupid idea? That's not important. What's important is that Steve fucked up and I didn't. Remember: never trust Steve. When people sit down to write open source, they write it the same way they would write code at work, because they've either never experienced anything better, or it was drowned out by the din. So their OSS is always almost as toxic as the situation I illustrated above. If, for some reason, you want to leave dangerous things laying around, you need way more safety interlocks than an underscore. If you should never call a function, what's the harm in making it expensive to call? Use a function name where the only reasonable interpretation of calling it is that the developer consented, with full knowledge. Make the function name 60 characters long with some colorful adjectives. Name it after the OWASP recommendation that says what a bad fucking idea it is to call this method. Giant neon lights. Fireworks. And a marching band. Do not look into laser with remaining eye.
- judge2020 6y ago
  Python's approach seems reasonable, where you have to go out of your way to learn about and perform this workaround: https://stackoverflow.com/a/9145524/3878893 https://stackoverflow.com/a/9145524/3878893
  - hinkley 6y ago
    ES6 has a way to name functions with Symbols, and Symbols with the same name are not equal. It's not used often but I've seen it used to give a secret back entrance to an object. Like a very limited version of friend functions/classes. If the symbol is not exposed, then you can't get anywhere in the neighborhood of calling it accidentally. I think if you do enough object introspection you can still get the function handle, but you could never mistake the resulting code for being anything other than farm fresh, Grade-A Cheese.
- gizmo686 6y ago
  If you enjoy sharing an address space with a malevolent agent of chaos, try accursedUnutterablePerformIO. https://hackage.haskell.org/package/bytestring-0.10.12.0/docs/Data-ByteString-Internal.html#v:accursedUnutterablePerformIO https://hackage.haskell.org/package/bytestring-0.10.12.0/doc...

hinkley 6y ago

It's still booby-trapping. I'm finding as I get older that a lot of programmers use their own mistakes to rationalize why they are the only ones who should be trusted with certain things. Well, of course I'm in charge. Last time Steve did something he pushed the big red button that shut down the whole server room. If I weren't in charge, then it would just be "Steve"s everywhere. Anarchy. Who put the red button there? Who thought having the big red button there might be a stupid idea? That's not important. What's important is that Steve fucked up and I didn't. Remember: never trust Steve. When people sit down to write open source, they write it the same way they would write code at work, because they've either never experienced anything better, or it was drowned out by the din. So their OSS is always almost as toxic as the situation I illustrated above. If, for some reason, you want to leave dangerous things laying around, you need way more safety interlocks than an underscore. If you should never call a function, what's the harm in making it expensive to call? Use a function name where the only reasonable interpretation of calling it is that the developer consented, with full knowledge. Make the function name 60 characters long with some colorful adjectives. Name it after the OWASP recommendation that says what a bad fucking idea it is to call this method. Giant neon lights. Fireworks. And a marching band. Do not look into laser with remaining eye.

judge2020 6y ago
Python's approach seems reasonable, where you have to go out of your way to learn about and perform this workaround: https://stackoverflow.com/a/9145524/3878893 https://stackoverflow.com/a/9145524/3878893
- hinkley 6y ago
  ES6 has a way to name functions with Symbols, and Symbols with the same name are not equal. It's not used often but I've seen it used to give a secret back entrance to an object. Like a very limited version of friend functions/classes. If the symbol is not exposed, then you can't get anywhere in the neighborhood of calling it accidentally. I think if you do enough object introspection you can still get the function handle, but you could never mistake the resulting code for being anything other than farm fresh, Grade-A Cheese.
gizmo686 6y ago
If you enjoy sharing an address space with a malevolent agent of chaos, try accursedUnutterablePerformIO. https://hackage.haskell.org/package/bytestring-0.10.12.0/docs/Data-ByteString-Internal.html#v:accursedUnutterablePerformIO https://hackage.haskell.org/package/bytestring-0.10.12.0/doc...