4 ms·
A less amusing name, but similar effect – `dangerouslySetInnerHTML` from React. https://legacy.reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml https
by danpalmer 3y ago
A less amusing name, but similar effect – `dangerouslySetInnerHTML` from React.
https://legacy.reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml https://legacy.reactjs.org/docs/dom-elements.html#dangerousl...
- rmilejczz 3y agoThis function name amuses me because it implies there is a “safelySetInnerHTML” method Also shouts out to the UNSAFE_component methods, you’re a real hipster if you used those before the prefix
- can16358p 3y agoNot exactly. If you are putting something inside the tag in React, you are implitly setting inner HTML the React way, managed by the virtual DOM. This method (actually not even a method but an attribute that probably calls a method if set) "bypasses" React to set the inner HTML of the element, hence "dangerous". (But I get what you mean of course, the reply was not to you but anyone who isn't familiar with React)
- rmilejczz 3y agoYou’re right it’s not even a method lol it’s a custom dom attribute. I had no idea
- initplus 3y agoOr ‘accursedUnutterablePerformIO’ from Haskell https://hackage.haskell.org/package/bytestring-0.11.4.0/docs/Data-ByteString-Internal.html#v:accursedUnutterablePerformIO https://hackage.haskell.org/package/bytestring-0.11.4.0/docs...
- bradrn 3y agoThe documentation is itself fairly funny, for those who don’t care to click ahead: > 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. > Witness the trail of destruction: https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7 https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da https://ghc.haskell.org/trac/ghc/ticket/3486 https://ghc.haskell.org/trac/ghc/ticket/3487 https://ghc.haskell.org/trac/ghc/ticket/7270 https://gitlab.haskell.org/ghc/ghc/-/issues/22204 > 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!
- gizmo686 3y agoOriginally, that function was just called "inlinePerformIO", with the relatively tame warning of: > Just like unsafePerformIO, but we inline it. Big performance gains as it exposes lots of things to further inlining. Very unsafe. In particular, you should do no memory allocation inside an inlinePerformIO block. On Hugs this is just unsafePerformIO https://hackage.haskell.org/package/bytestring-0.9/docs/Data-ByteString-Internal.html#v%3AinlinePerformIO https://hackage.haskell.org/package/bytestring-0.9/docs/Data... At some point, this function was moved to the newly created "Deprecated and unmentionable" group of functions with the comment > Deprecated: If you think you know what you are doing, use unsafePerformIO. If you are sure you know what you are doing, use unsafeDupablePerformIO. If you enjoy sharing an address space with a malevolent agent of chaos, try accursedUnutterablePerformIO. At this point, the two depreciated and unmentionable functions were actually just aliases of each other, with InlinePerformIO being depreciated, and accursedUnutterablePerformIO being merely unmentionable. https://hackage.haskell.org/package/bytestring-0.10.10.1/docs/src/Data.ByteString.Internal.html#inlinePerformIO https://hackage.haskell.org/package/bytestring-0.10.10.1/doc... It wasn't until version 0.11.0.0 that the friendly sounding name was finally removed.