so, you've seen ™ and ™️ before. but like. why are there two. well, i have an explanation! the answer is: FE0F
first, unicode. unicode is a standard definition of a bunch of codepoints, where a codepoint is just a number with meaning. for example, unicode codepoint U+263A refers to ☺︎, or "White Smiling Face", and U+1F431 refers to 🐱, or "Cat Face"
so, lets start by looking at the codepoints for ™. decoding it, it becomes the codepoint U+2122, referred to as "Trade Mark Sign". this was added in unicode 1.1 in 1993, a decent time ago!
next, the codepoints for ™️. decoding it, we get two codepoints! U+2122 (™︎) and U+FE0F. wait. who is FE0F. why is he in my emoji
well, unicode isn't as simple as a series of codepoints that refer to single characters. take a look at é̗ for example. this is three codepoints, U+0065 (Latin Small Letter E), U+0301 (Combining Acute Accent), and U+0317 (Combining Acute Accent Below). the first codepoint is simple enough, it's just e. the next two, however, are combining codepoints. this means that they combine with the codepoint before them to modify it. U+0301 adds an acute accent above the previous codepoint, and U+0317 adds an acute accent below the previous codepoint. this example specifically isn't very useful (i don't know any language with a é̗ character beyond conlangs), but it becomes very useful for languages that use a lot of diacritics. imagine if we had to make a new set of characters for each set of possible diacritics! big waste of space, we shouldn't have done that!
so, what is U+FE0F? well, it's a special codepoint called "Variation Selector-16". variation selectors are a reserved block of 16 unicode codepoints. only some have been defined, but among those currently in use are U+FE0E (VS15) and U+FE0F (VS16). from wikipedia: "VS15 and VS16 are reserved to request that a character should be displayed as text or as an emoji respectively." so, what's happening with ™️ is that it's combining a U+2122 (™) and a U+FE0F (Variant Selector-16) to create an emoji version of ™. they're the same character, just that one has been instructed to become an emoji!
also, for the interested, here's the word "unicode" with a shit ton of combining characters: ù́̂̃̄̅̆̇̈̉n̖̗̘̙̐̑̒̓̔̕i̡̢̧̨̠̣̤̥̦̩c̴̵̶̷̸̰̱̲̳̹ò͇͈͉́͂̓̈́͆ͅd͓͔͕͖͙͐͑͒͗͘eͣͤͥͦͧͨͩ͢͠͡. what appears to be seven letters is actually 77 codepoints, taking up 147 bytes when encoded in utf-8. or 156 in utf-16. or 312 in utf-32. why does anyone use utf-16 if it's longer? historical reasons :3
@mia honestly, i respect utf-16, its not that practical but having everything in the basic multilingual plane be just one codepoint is just nice when doing low level shenanigans
@argv_minus_one@mia we are marching fullspeed ahead in the 2037 bug because “y2k wasnt a big deal in the end”, i can assure you we will simply get fucked
like, every time i read about OOP i leave further convinced that its just a tedious way to apply other paradigms in a way that makes them inconvenient while contributing nothing useful of its own
like, when i started out and knew fuckall about programming theory i just hated the abstractions it provides because i found them unintuitive
then i saw encapsulation through a module lens rather than an object lens, and suddenly its like “oh yea that’s gotta be indispensable when working in a group | on a large long-term project | on a library, shame its tucked into the unintuitive set of abstractions“
then i saw the bold claim that actually its polymorphism that makes OOP special, and immediately heckled it because the only prerequisite to ad-hoc polymorphism is a type system and something roughly equivalent to a switch statement (if-else does the trick)
but now im looking into the claim deeper and it just keeps becoming more wrong? cause even the more advanced parametric polymorphism (generics/templates) you find in the more well-known object systems (but not all, CLOS notably lacks this) isn’t just not specific to OOP but its an essential core feature to haskell and other type-heavy functional languages that give me a migraine (the one constant between all of these)
@astrid i have to respect dogmatic OOP for bringing together genuinely good and useful paradigms in a way where they’re all designed to interoperate neatly, and somehow fuck it up so badly i don’t want to use it
@astrid thats the thing tho, an object without encapsulation is just a datatype that holds functions and data and lets you access them by defined names
@astrid the worst part is because a lot of games integrate with steam’s infrastructure for networking, they cant either, which is a big reason why most steam games are ipv4 only
can't wait to deal with the problem in about a year or two where 2 of the 4 competing nix implementations evaluate and store the same derivation in very slightly different ways
@1 drum springs a leak and a green substance begins to ooze out. moments later that substance begins to take the shape of a hand further trying to pull itself out of the drum until it is all over the floor.
soon after the ooze has regained its strength it begins to morph into a somewhat humanoid shape as it vocalises in a gurgly tone “oh excuse its rudeness for not greeting you earlier, due to circumstances outside of its control it was sadly unable to. may it apologise with a cup of tea and some biscuits?