RFC: handling of boolean arguments in methods

Next topic

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 [email protected] \| 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 [email protected]	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