RFC: handling of boolean arguments in methods

Wednesday 29 December 2010 5:35:16 am

Hi !
I was thinking about how boolean function/method arguments are currently handled in eZ Publish.
Calls to methods with boolean arguments will look like this:

method( $stringArgument, true, false )

When reading this call, without using code tools like code insight, you don't know what true & false are for. Within PHP itself, these days, we see a lot of mask arguments:

$iterator = new FilesystemIterator( $path,
    FilesystemIterator::KEY_AS_PATHNAME | FilesystemIterator::CURRENT_AS_FILEINFO );

While it requires writing more code, I feel like it strongly improves code readability, and actually improves the API itself by allowing more than one value for one option.
With the proper API in the framework itself, it would be easy to use these in our code. Any comment ?

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Wednesday 29 December 2010 2:08:27 pm

+1

http://www.mugo.ca
Mugo Web, eZ Partner in Vancouver, Canada

Thursday 30 December 2010 1:56:27 am

+1

Maxime Thomas
maxime.thomas@wascou.org | www.wascou.org | http://twitter.com/wascou

Company Blog : http://www.wascou.org/eng/Company/Blog
Technical Blog : http://share.ez.no/blogs/maxime-thomas

Tuesday 11 January 2011 2:35:21 am

I agree with Bjorn here: use constants whenever options are more than one, but for simple booleans a global rewrite is imho not necessary - we have more important things to fix ;-)

Besides, why are booleans specially harder to understand than passing a value of say 25 or "hello" as function parameter?

A weird syntax I have seen in use is this:

$result = func( $do_this = true )

where the variable "do_this" servers no other purpose than reminding the reader the name of the parameter.

Not sure everybody would like it though: not only it is unconventional, but it might be error probe, too.

Principal Consultant International Business
Member of the Community Project Board