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

Get rid of those boolean function parameters (2015)

mortoray.com

Post reply on HN
Print view View original

91–100 of 119 posts

Re: Get rid of those boolean function parameters (2015)

#91

Post by magicalhippo »

CRConrad wrote: post #84
magicalhippo wrote: post #53

In Delphi I try to use sets over boolean parameters. Then I can easily add new possible set members instead of introducing more parameters. type FuncParam = (fpDoThis, fpDoThat); type FuncParams = set of FuncParam; function MyFunc(arg1, arg2: integer; params: FuncParams): integer; begin result := 0; if (fpDoThis in params) then result := DoThis(arg1); ... end; // supply directly MyFunc(123, 42, [doThis, doThat]); //…

> Delphi ain't the most elegant language out there Citation, as they say, needed. :-)

Any anonymous function will do :P

Not knocking it, after all it's my daily driver. You can do quite a lot with it these days and it can be quite productive.

Re: Get rid of those boolean function parameters (2015)

#92

Post by fendy3002 »

stnmtn wrote: post #76
flavius29663 wrote: post #49

Earlier quoted context omitted.

pizza is very suitable for the builder pattern: CreatePizza() .WithBacon() .With(artichoke) .Build(); or any combination of the above: CreatePizza() .WithMussroom() .Build() Even better, you can add new ingredients without changing any of the existing signatures: CreatePizza() .WithProsciuto() .WithTomatoSauce() .Build()

What is the difference of this and doing an object paramater, similar to JS? createPizza({bacon: true, artichoke: true}); This has the same benefit you describe of being able to add parameters without altering any old call sites createPizza({prosiuto: true, tomatoSauce: true});

Not OP, but it's useful for if:

- something is done to object when some props is set or validation, such as .withStuffedCrust("cheese"), it'll set the internal props as crust="stuffed" and stuffContent="cheese"

- it's branching. So rather than making user looking for the components or configuration themselves, library author can guide them with builder. Such as:

  myVehicleBuilder.withSixTires().withTrailerAttachment().attach(container)
In this case withTrailerAttachment (and possibly withOpenBack or withBox) won't show up if you call withTwoTires(), and attach won't show up if you don't call withTrailerAttachment().

Re: Get rid of those boolean function parameters (2015)

#93

Post by fxtentacle »

Zababa wrote: post #89
fxtentacle wrote: post #80

Earlier quoted context omitted.

With a good IDE, the first one can be configured to look like the 2nd one. But the 2nd one will always be more verbose, no matter if you need it or not. So I'd choose the first one.

The first one will probably look confusing if you're looking at the repo through a web interface though. Or if you're looking at examples in a readme. I have personally never been limited by my "raw code writing speed", and if that was the case, I would look into touch typing/autocompletion before sacrificing readability.

Most source code will also be badly readable if you print it out ;)

So should we change our use of C++ to make it more GitHub-friendly? Or should we fix GitHub to properly work with the C++ source code that already exists?

Re: Get rid of those boolean function parameters (2015)

#94

Post by fxtentacle »

tsimionescu wrote: post #31
10x-dev wrote: post #29

Earlier quoted context omitted.

> every bit of software that presents this program not only to understand my programming language You can either change your program to fit existing tools, or you can build smarter tools. I prefer the latter. > code itself is a presentation layer Not for the tool it isn't edit: I think we can all agree that ideally we fix this in the language itself by adding optional named parameters

No matter how smart the tool is, unless it can see the definition of the function, it can't guess the parameter name. Code is often shared on mail, chat programs etc, requring me to send compilable code snippets to get nice presentation out of a blob of text would be significant overkill...

Your IDE could automatically add those annotations as rich text or embedded HTML when you copy the source code out from the IDE into the E-Mail.

Re: Get rid of those boolean function parameters (2015)

#95

Post by debacle »

CRConrad wrote: post #87
debacle wrote: post #79

Earlier quoted context omitted.

It's a readability optimization, not a performance optimization.

What's wrong with readability optimizations, be they micro- or macro-?

The next person to read that isn't going to say "Wow this is so clever." They are going to say "Wow this guy didn't know about booleans."

Re: Get rid of those boolean function parameters (2015)

#96

Post by rocqua »

InitialLastName wrote: post #54
rocqua wrote: post #27

Earlier quoted context omitted.

The 'require named argument' solution is less strong than the enum solution. (An enum is also available in python). Indeed re-use of the plain bool in Python is less clear, as is passing it on. This makes the enum the best solution. However, enum is also a heavy-duty solution. It requires slightly more typing, but more importantly, it requires exporting an enum to all call-sites. Both in C++ and in python this is not…

>... it requires exporting an enum to all call-sites. Both in C++ and in python this is not desirable. Given the reasonable namespacing that C++ and python [modules] provide, and that you have to export the complete calling specification of the function to the caller anyway (whether it's an enum, a positional boolean or a keyword argument), what's the drawback of the enum option?

In Python, if you use ' import x from' now it becomes 'import x, y from'. Can especially make refactoring more work.

If you use namespaced imports then the call is going to become very long by having the package name included twice.

In C++ you are dealing with needing to drop the enum in a header file, requiring a two file change and making headers bigger. The call-side has the same potential namespace problem, but less badly.

Re: Get rid of those boolean function parameters (2015)

#97

Post by CRConrad »

debacle wrote: post #95
CRConrad wrote: post #87

Earlier quoted context omitted.

What's wrong with readability optimizations, be they micro- or macro-?

The next person to read that isn't going to say "Wow this is so clever." They are going to say "Wow this guy didn't know about booleans."

Did you just skip over the beginning of the discussion, where everyone agreed that having a bunch of anonymous booleans is bad for readability, and circle back to advocating the status quo that everyone else is trying to improve on?

Re: Get rid of those boolean function parameters (2015)

#98

Post by lispm »

mtreis86 wrote: post #24

There are a couple ways to approach it in Common Lisp, probably a few more than I have here. One, optional and keyword arguments can have defaults. (defun calc-formula (ia ib &optional (gain t)) ...) Two, you could use a dynamic variable and a closure. Outside the body of the let the gain var returns t, within the body of the let it returns nil. (defvar *gain-enabled* t) (defun calc-with-gain (ia ib) ...) (let ((*gai…

DEFVAR declares a variable to be special. That causes ALL uses of that variable to use dynamic binding.

The function inside a LET with a dynamic variable does not create a closure. If one calls CALC-WITHOUT-GAIN later, there is no binding - unless there is another dynamic binding of that variable by a different LET active.

Re: Get rid of those boolean function parameters (2015)

#99

Post by CRConrad »

flavius29663 wrote: post #88
CRConrad wrote: post #86

Earlier quoted context omitted.

Nothing to stop you from doing the same within the code of the multi-parameterized single function, is there? if Shrimp in Fillings then begin Add(Shrimp); Add(ShrimpOil); // So yummy together Fillings.Remove(Jalapenos); // Don't go together end; if Jalapenos in Fillings then begin Add(Jalapenos); end; etc. No?

You just moved the problem to a different layer. In your case you would end up calling your function like this: DoToppings(true, false, true, true); Whereas in my case you would call the builder directly with (only) the params you want different than the defaults. You could use named arguments, but that doesn't solve the problem completely. You will still have a large method signature, hard to use, harder to refactor…

> You just moved the problem to a different layer.

No, I think you're misunderstanding. Weird... Aha: My fault, sorry.

> In your case you would end up calling your function like this: DoToppings(true, false, true, true);

What?!? Heck no, that wasn't what I meant, why would you think that? [Goes repeatedly clicking "parent"] Aha, I see: Sorry, the threads and sub-threads have branched so I got confused as to where we are.

No, that wasn't what I meant at all. I got this sub-thread mixed up with sibling ones, and was talking in the context of languages with native enums and sets (roughly, Pascal and its descendants), where you do:

  type PizzaFilling: (tuna, shrimp, peperoni, ham, gorgonzola, jalapeno) ; // Etc, etc...
       PizzaFillings: set of PizzaFilling ;
  function MakePizza(PizzaFillings);
And then the body of function MakePizza uses that set as per my GP comment.

It's called not with a bunch of anonymous booleans like you wrote, but with a set of enumerated descriptively-named fillings as a parameter; say, a TakeOrder function builds this set by starting from an empty one (or perhaps tomato and cheese already in as defaults?) by the customer's specifications, and then calls

  MakePizza(OrderedFillings);
> Sure, there is no black and white, and depends on the language,

Yeah, I was attempting to show how the problem you mentioned doesn't exist in languages with better / saner types. Again, sorry for getting the contexts mixed up; I though that was what you were talking about too, and just didn't get.

> the builder pattern is a good tool to have in the toolbox.

Urgh, yeah, I suppose so... At least in languages where you need it, because they lack other more basic (Heh!) amenities.

Re: Get rid of those boolean function parameters (2015)

#100

Post by Zababa »

fxtentacle wrote: post #93
Zababa wrote: post #89

Earlier quoted context omitted.

The first one will probably look confusing if you're looking at the repo through a web interface though. Or if you're looking at examples in a readme. I have personally never been limited by my "raw code writing speed", and if that was the case, I would look into touch typing/autocompletion before sacrificing readability.

Most source code will also be badly readable if you print it out ;) So should we change our use of C++ to make it more GitHub-friendly? Or should we fix GitHub to properly work with the C++ source code that already exists?

I think it's not an issue of Github or not Github. Either you think of code as plain text first, or you think plain text is just another way to present it. I think of code as plain text first, and thus I like programming languages that don't need to be analyzed to be displayed properly. Other people may not think the same.
Post reply on HN