eZ Community » Forums » Developer » RFC: handling of boolean arguments in...
expandshrink

RFC: handling of boolean arguments in methods

RFC: handling of boolean arguments in methods

Wednesday 29 December 2010 2:35:16 pm - 6 replies

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 ?

Wednesday 29 December 2010 3:29:47 pm

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

Wednesday 29 December 2010 11:08:27 pm

+1

Thursday 30 December 2010 12:26:34 am

Never thought about this question, but it makes sense.

Thursday 30 December 2010 10:56:27 am

+1

Thursday 30 December 2010 11: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.

Tuesday 11 January 2011 11: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 blunk.gif Emoticon

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.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu