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

I keep tripping over "true, false, true"

allthingssmitty.com

Post reply on HN
Print view View original

21–30 of 62 posts

Re: I keep tripping over "true, false, true"

#21

Post by dematz »

First, sentences like "Not because it’s complicated. Just because I have no idea what I’m looking at." and "Tiny interruption. Still annoying every time." fatigue me, it's like you have an editor who, no matter what the content is, tries to spice up your writing with lots of little punchy exclamations, not everything needs such emphasis

Second, this may differ a bit from language to language, but maybe those booleans should not be a boolean: https://gleam.run/documentation/conventions-patterns-and-ant... for example isAdmin boolean could instead be a UserRole custom type, with variants Normal and Admin, which is easier to understand in the function call, and extendable with another Moderator (or whatever) variant

Re: I keep tripping over "true, false, true"

#23

Post by megiddo »

dematz wrote: post #21

First, sentences like "Not because it’s complicated. Just because I have no idea what I’m looking at." and "Tiny interruption. Still annoying every time." fatigue me, it's like you have an editor who, no matter what the content is , tries to spice up your writing with lots of little punchy exclamations, not everything needs such emphasis Second, this may differ a bit from language to language, but maybe those boolean…

Exactly my thought. I know languages differ in support ... but enum is right there.

Re: I keep tripping over "true, false, true"

#24

Post by MathMonkeyMan »

edwcross wrote: post #16

OCaml has had labeled arguments for decades, so I assumed other languages would have added something similar by now. In C-style, it would be like: createUser(user, ~isAdmin:true, ~sendWelcomeEmail:false) Even though in OCaml's functional style it is actually like this: createUser user ~isAdmin:true ~sendWelcomeEmail:false Using the fact that a variable named exactly like a labeled argument is automatically assigned t…

You can do this as a convention in javascript since 2015, but I haven't seen a library that does it:

    > function foo({a, b, c}) {
    ... return {x: a, y: b, z: c};
    ... }
    undefined
    > foo({a: 1, b: 2, c: 3})
    { x: 1, y: 2, z: 3 }
    > const a = 'A', b = 'B', c = 'C';
    undefined
    > foo({a, b, c})
    { x: 'A', y: 'B', z: 'C' }
    >

Re: I keep tripping over "true, false, true"

#28

Post by Dagonfly »

edwcross wrote: post #16

OCaml has had labeled arguments for decades, so I assumed other languages would have added something similar by now. In C-style, it would be like: createUser(user, ~isAdmin:true, ~sendWelcomeEmail:false) Even though in OCaml's functional style it is actually like this: createUser user ~isAdmin:true ~sendWelcomeEmail:false Using the fact that a variable named exactly like a labeled argument is automatically assigned t…

It's the one thing I miss from Swift when I'm using literally any other language. Interal and external parameter names. I would love for Rust to adopt:

  fn foo(namedParam internalName: bool) { // use internalName here }

  fn foo(unnamedParam: bool)

Re: I keep tripping over "true, false, true"

#29

Post by Dwedit »

This is where something like "const bool isAdmin = true, sendWelcomeEmail = false" helps. Now your literal values aren't in the function call arguments anymore, but instead their meaning is, you just need to look elsewhere (probably the line right above it) to find their values.

Re: I keep tripping over "true, false, true"

#30

Post by eithed »

edwcross wrote: post #16

OCaml has had labeled arguments for decades, so I assumed other languages would have added something similar by now. In C-style, it would be like: createUser(user, ~isAdmin:true, ~sendWelcomeEmail:false) Even though in OCaml's functional style it is actually like this: createUser user ~isAdmin:true ~sendWelcomeEmail:false Using the fact that a variable named exactly like a labeled argument is automatically assigned t…

Think the issue is not with named parameters per se, but with mixing domain logic = there are two different user creation flows, that should be doing two different things (or mostly different things), but are guarded with boolean flag.

As author points out: "So I’ll usually just make it explicit:

createAdminUser(user);

createRegularUser(user);

Now there’s not much left to interpret. To be fair, this isn’t always bad. Sometimes this is completely fine:

toggleMenu(true);

That’s clear enough. This tends to work when:

- the meaning is obvious

- the function is small and local

- there’s only one flag "

Post reply on HN