Forums / Developer / RFC: handling of boolean arguments in methods

RFC: handling of boolean arguments in methods

Author Message

Bertrand Dunogier

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

Carlos Revillo

Wednesday 29 December 2010 6:29:47 am

+1. If it improves code readability (as it will) then it should be done :).

Peter Keung

Wednesday 29 December 2010 2:08:27 pm

+1

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

Thiago Campos Viana

Wednesday 29 December 2010 3:26:34 pm

Never thought about this question, but it makes sense.

eZ Publish Certified Developer: http://auth.ez.no/certification/verify/376924

Twitter: http://twitter.com/tcv_br

Maxime Thomas

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

Björn Dieding@xrow.de

Thursday 30 December 2010 2:24:00 am

-1/+1

You say:

>it actually improves the API itself by allowing more than one value for one option.

Then it is not a boolen anymore, if you have many options. For true boolean useage I would still keep TRUE / FALSE / YES / NO for the quickness of writing. A boolean is self explainable. The downside is that you would need to lookup "FilesystemIterator::KEY_AS_PATHNAME | FilesystemIterator::CURRENT_AS_FILEINFO" each time in the DOC if you do not use the code that much.

In areas where you need many values it is fine.

Also do not forget to update the coding guide lines.

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Gaetano Giunta

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