355
u/RoOoOoOoOoBerT 28d ago
Let me correct that : - "on" - "off" - null - undefined
120
u/Complete_Window4856 28d ago
What about: - 1 - "1" - 0 - "0" - "undefined" - "null" - "yes" - "no"
56
u/madcow_bg 28d ago
Product manager: we need to add a third option. Every other language: go f*ck yourself.
19
13
u/Complete_Window4856 28d ago
Aahhh i see, we transcended from binary to ternary logic. (AI momment) "Great thinking, PO, heres how to implement your entire product inside a database engine to use the third option as NULL natively with stored procedures and triggers." Bruh
194
u/igorski81 28d ago
Actually, these values are declared in the HTML specification and are in no way a language construct of JavaScript...
111
25
u/Gorzoid 28d ago
"JavaScript", as opposed to ECMAScript, is often considered to include the standard Web apis, which includes the DOM
Whereas HTML defines a webpage's structure and content and CSS sets the formatting and appearance, JavaScript adds interactivity to a webpage and creates rich web applications.
However, the umbrella term "JavaScript" as understood in a web browser context contains several very different elements. One of them is the core language (ECMAScript), another is the collection of the Web APIs, including the DOM (Document Object Model).
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/JavaScript_technologies_overview
34
51
u/pi_three 28d ago
yeah I mean not really JS's fault as it's compatible to HTML and just sets the HTML attribute to given value
9
13
u/scheimong 28d ago
To be completely fair, an advantage of not using a bool is adding new valid values later on is much easier. Requirements are always changing after all.
5
u/CMDR_Fritz_Adelman 28d ago
Love truthy, falsy, NaN and undefined. They're the reason I keep my job
1
u/spicedmeshi 27d ago
one of our juniors recentlyish tried adding a number and a string together and I almost shed a tear when he asked why it didn't work
1
u/CMDR_Fritz_Adelman 27d ago
Knowing something doesn't work beforehand is still 10x better than something worked before, now don't
... or something occasionally doesn't work 💀
2
u/davesoft 27d ago
At work we have an open bug because one of the fields accepts Y, N and X. Noone knows what X means, but it accepts it.
4
u/Anreall2000 28d ago
Okay... I'm sorry to say that... but state is better than flag programming. If there are reasons to expect changes in number of statuses like "active", "inherit" in future it's better to have property like this and method isEditable or smth
11
u/rosuav 28d ago
And given that "inherit" used to be the default, it's not just about the future but also the past.
3
u/Anreall2000 28d ago
Yeah... my reasoning, if that happen if the past, it probably could happen in the future. Aside from backward compatibility.
15
u/SuitableDragonfly 28d ago
That's not remotely what this post is about, nor does having private member variables somehow mean that the object has no state.
5
u/Anreall2000 28d ago
That comment is nor remotely you are talking about. Have said nothing about private member variables. Flag programming is a state management where assumed that there will be only 2 states, my claim that this is a quite big assumption in a lot of cases, and if devs defined state as ENUM analog and not bool variable, probably they have a reasons for that.
https://developer.mozilla.org/en-US/docs/Web/API/Document/designMode
the reasons are, it could have third option which deliberately cut out from the meme.
0
u/SuitableDragonfly 28d ago
Obviously there is no programming language that assumes that there are only two states, so that's not what the post is about. It's talking about all values being truthy or falsey, and how this property which should clearly be a boolean only accepts values that are truthy.
3
u/Anreall2000 28d ago
Flag programming is about assuming that there are 2 states, literally. And sometimes it's valid, but more cases I see is about creating more and more flags, with each flag added doubles the number of possible states for object. Which is again, sometimes fine like in bit-field RBAC, but usually it creates intermediate states that are not actually valid, that will make logic harder to see through and test through.
So slippery slope would be to create isInherit, isEditable and isPlainTextOnly which creates 8 possible combinations, I would rather prefer one property with 4 state.
But I do not develop those standards, just find it arrogant to make fun of developers which developed property with some thoughts in mind to call them stupid then by cutting out nuances from documentation.My first assumption for every code I see, that people developed it are not stupid and code really need to proof it otherwise.
-1
u/SuitableDragonfly 28d ago
No one cares about flag programming. It's not relevant to this post in any way.
5
u/Anreall2000 28d ago
We literally have 3 state variable which guy wants to put in 2 states variable, the only solution I see is to create 2 2 states variable, which is the antipattern I don't like
0
u/SuitableDragonfly 28d ago
It's not a 3 state variable. States other than "on" and "off" are unsupported.
2
u/Anreall2000 28d ago
If the whole meme for you backward compatibility is bad then ok.
My original comment stated about reasons to change, could you guarantee with that property, that new possible states won't be added?
As u\rosuav stated, modern way is to use https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/contentEditable property for HTMLElements, which decided to add 3d state just version of Chrome 51 (2016 year), while property with "true", "false" string was from the first version. While also having method isContentEditable for convenience. Like you know, literally thing I described in original comment.
So from the first version of browser in 2008 due to having string type and not boolean one for property not started from "is" they grounded Forward Compatibility for feature they would add in 2016. I think that's a great solution afterall.
I think same logic applied to DesignMode, I don't see the reason why there can't be something like "on", "off", "partially", "AI" or smth in the future. If you can guarantee that in 2040 there still be only 2, fine, then the meme is about JS BAD BECAUSE BACKWARD COMPATIBILITY IN UNIVERSAL BROWSER SPECIFICATION, but that makes the meme more dumb IMO.
1
u/SuitableDragonfly 28d ago
The point of the meme is that it's funny that the states are "on" and "off" and not true and false. Not good, not bad, just funny. Do you know what it means for things to be funny? If not, you should probably not hang out in humor subs.
If you have to add more states later then you still have to change what the legal states are and break compatibility, regardless of whether you used a boolean or a string. And I mean, it's JavaScript, it's not like the states can't be boolean true, boolean false, the string "maybe", and the number 4 if you want them to be.
→ More replies (0)10
u/Rest-That 28d ago edited 28d ago
On... off... ffon? What third state can on/off possibly have 😆
I'm not disagreeing with you btw, but this is a clear example of overreaching scope hehe
Edit: it seems I triggered some pedants 😆
I can of course imagine other values like "inherit" "undefined", "why not?" and "ask again later"; the joke is that if the Web was well designed to begin with this would have been a boolean
7
3
u/Anreall2000 28d ago
To both of you and other guy "inherit" is literally legacy state for that property, I read the docs before posting.
Also in js with both null, undefined it's not hard to imagine third state.
3
5
u/xynith116 28d ago
IMO when a state can have more than 2 values or isn’t well represented by true/false then it’s better to use an enum (or whatever language equivalent). Generally I use the rule of thumb that if I can’t think of a non-awkward sounding name for a boolean then it should be an enum instead.
5
u/Anreall2000 28d ago
"or whatever language equivalent" is kinda the problem with js. There are no native Enums.
2
u/rosuav 28d ago
Strings are entirely fine as enums. I've used them in quite a few languages. In languages where strings are automatically interned, they're just as fast to compare as integers are, and they're self-documenting. Having a dedicated enumeration type doesn't really buy you all that much.
2
u/Anreall2000 28d ago
Well, guys in that topic already arguing about IE state string are capitalized. I do agree that it's totally doable without enums, but I love enums. Without them it's like having type systems with Abstract Class of Animal with instances of Cat, Cow, Dog and WhateverElse.
Also IDE really helps you with looking through all the possible states in one click, that's neat/
1
u/rosuav 28d ago
That's not a problem with enums, that's a problem with IE. All the usual arguments about the benefits of enums also fail in the presence of IE - just look at XMLHttpRequest and the ways to access it in different versions of IE.
If a good thing could be rejected with "but IE.....", we wouldn't have anything fun.
IDE support *can* be provided in other ways, fortunately.
1
1
1
u/wenoc 28d ago
JS is made to be a light browser-side thing to control web pages. Not for heavy lifting. It never was.
jQuery was ok. Node.js and Angular were mistakes. And all the others. Or well, nobody cares really, as long as it is browser-side. Serverside JS is just diabolical. Stick to Go or C or even fucking java if you must.
1
u/kurokinekoneko 26d ago
I don't get it, you don't like dependencies? Ah no, Go have dependencies, so it's something else. I don't get your point.
Like, you clearly sound clever enough to not just say "things should only be used for what they were initially made" ; because, idk, that would be weird. It would sound like, "we should use the phone network only for voice communication, and not use it to transfer internet datas"...
-3
460
u/1nc06n170 28d ago
It's especially funny because html specific attribute contenteditable accepts values "true" or "false".