Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use booleans (2019)

luu.io

Post reply on HN
Print view View original

111–120 of 152 posts

Re: Don't use booleans (2019)

#111

Post by CoastalCoder »

Gibbon1 wrote: post #83
cassepipe wrote: post #73

It seems it's not so much booleans than using unnamed parameters for option parameters. I find myself using this style in C, it does not prevent a mix-up if someone refuses to use named field designators but it works ok : typedef struct options_s { bool toggle_case; bool strip_whitespace; } options_s; char *modify_string(char *str, options_s options) { if (options.toggle_case) { /**/ } if (options.strip_whitespace) {…

If a giant meteor took out WG14 we might get named arguments in C modify_string(.str=str, .options = { .toggle_case = true, .strip_whitespace = false });

I've wanted a similar thing for C++.

Anyone know what the reasons have been for the language not adopting this?

Re: Don't use booleans (2019)

#112

Post by yen223 »

zogrodea wrote: post #103
hardwaresofton wrote: post #98

Earlier quoted context omitted.

Sorry, can you explain this more? I somehow still don't understand. How is this different from a const object style enum? Or are you more referring to the sum type enum as the better choice here to avoid this. Generally, if you remove an enum variant, the compiler should warn you if you've used it anywhere else (though of course it can't figure out a dynamic usage)... But this seems like a problem mostly for dynamic…

My understanding of the comment is that it’s in the context of saving an enumeration-object into a database. Like Typescript might (for example) represent enums as integers like 1, 2, 3... at runtime. What happens if you decide to store a “delivery status” enum in a database? You would just be saving a number into the database, which can be hard to understand. If it’s a string, then the value stored in the database i…

Yeah, one of the annoyances I have with using Enums, even in other languages, is that its serialised value isn't always obvious. Something like direction.NORTH could serialise into "NORTH" or some integer, depending on the language and the implementation.

I like Typescript's union of string literals approach because its serialised value is never in question. I know exactly what "NORTH" serialises to.

Re: Don't use booleans (2019)

#113

Post by ijlx »

CoastalCoder wrote: post #110
kazinator wrote: post #77

This goes away in a language that allows arguments to name the parameters: fetch(accountId, history = true, details = false); However, I would be opposed if this mechanism is permitted to perturb the order of fixed arguments. If history is the third argument, rather than the second, it should error. I.e. "history = true" means "we are passing true as the second parameter, which we believe to be called 'history', on p…

Is this an example from some well-known compiled language? I work mostly in C++, and this is a feature I've wished for for a long time.

Swift and C# appear to have this feature, though they use the syntax

  fetch(accountId, history: true, details: false);

Re: Don't use booleans (2019)

#114

Post by danhau »

junon wrote: post #94
hardwaresofton wrote: post #67

Tangentially -- use languages that have great enum support. Well you knew what was coming -- Rust enums are excellent[0], and so are Haskell's[1] (try and spot the difference between an enum and a record type!)... But that probably won't help you at $DAYJOB. A bit more on topic though -- I'd like to see a strong opinion on Option versus SomeEnum containing a Missing variant. I usually lean towards Option but I wonder…

Option is the better of the two. With a missing variant, there's no way to encode "infallibly successful". All call sites would have to check for a missing variant in all cases.

This. Enum with a “missing“ variant is basically the billion dollar mistake again… kinda.

Re: Don't use booleans (2019)

#115

Post by yen223 »

CoastalCoder wrote: post #110
kazinator wrote: post #77

This goes away in a language that allows arguments to name the parameters: fetch(accountId, history = true, details = false); However, I would be opposed if this mechanism is permitted to perturb the order of fixed arguments. If history is the third argument, rather than the second, it should error. I.e. "history = true" means "we are passing true as the second parameter, which we believe to be called 'history', on p…

Is this an example from some well-known compiled language? I work mostly in C++, and this is a feature I've wished for for a long time.

Kotlin does this

https://kotlinlang.org/docs/functions.html#named-arguments

Re: Don't use booleans (2019)

#117

Post by gherkinnn »

CoastalCoder wrote: post #110
kazinator wrote: post #77

This goes away in a language that allows arguments to name the parameters: fetch(accountId, history = true, details = false); However, I would be opposed if this mechanism is permitted to perturb the order of fixed arguments. If history is the third argument, rather than the second, it should error. I.e. "history = true" means "we are passing true as the second parameter, which we believe to be called 'history', on p…

Is this an example from some well-known compiled language? I work mostly in C++, and this is a feature I've wished for for a long time.

C# is well known I guess

https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

Re: Don't use booleans (2019)

#118

Post by einburger »

CoastalCoder wrote: post #110
kazinator wrote: post #77

This goes away in a language that allows arguments to name the parameters: fetch(accountId, history = true, details = false); However, I would be opposed if this mechanism is permitted to perturb the order of fixed arguments. If history is the third argument, rather than the second, it should error. I.e. "history = true" means "we are passing true as the second parameter, which we believe to be called 'history', on p…

Is this an example from some well-known compiled language? I work mostly in C++, and this is a feature I've wished for for a long time.

If the code base supports designated initializers I'll use them as a way of getting named parameters like so:

struct SomeArgs { bool normalize{false}; int stride{2}; char ch{'x'}; ... some other stuff };

void someFn(SomeArgs args);

someFn({ .stride = 1, .ch = 'y' }); someFn({ .normalize = true });

not as simple as python but it's close-ish and more readable than: someFn(false, 2, 'c');

Re: Don't use booleans (2019)

#119

Post by tubthumper8 »

simondw wrote: post #91
the_gipsy wrote: post #82

Earlier quoted context omitted.

An Option has the advantage that you con chain it with other Option/Result operations like map, and_then, etc. I think this would be called being "monadic". The advantage of Enum with Missing variant is that it's more expressive, and that you don't have to nest access in the Some matching. Generally I prefer Option , and often you can match directly with Some(Variant) to avoid nested matches.

> map, and_then, etc. I think this would be called being "monadic". Strictly speaking, I think providing "map" just makes it functorial. Monadic would need a flatmap. (In addition to the other functor and monad requirements, of course.)

The "and_then" that they mentioned is the flatmap

Re: Don't use booleans (2019)

#120

Post by js2 »

CoastalCoder wrote: post #110
kazinator wrote: post #77

This goes away in a language that allows arguments to name the parameters: fetch(accountId, history = true, details = false); However, I would be opposed if this mechanism is permitted to perturb the order of fixed arguments. If history is the third argument, rather than the second, it should error. I.e. "history = true" means "we are passing true as the second parameter, which we believe to be called 'history', on p…

Is this an example from some well-known compiled language? I work mostly in C++, and this is a feature I've wished for for a long time.

Objective-C. Swift.
Post reply on HN