Julio, I'm sure that you hate what I'm saying in the nicest possible way ;-)
I think that you more-or-less got what I was saying, although a bit less ugly that. This sort of code is really horrible in every way: OB SET($options;”o4”;p4;”o5”;”";”o6”;”";”o7”;”") or MyMedioreMethod(->[Table];5;Current date;"";"";0;5) So, agreed, that's just nasty. Mostly thinking things through...I may land right back where I've been for years with optional parameters, but sometimes it is helpful to revisit old habits. For object creation in general, I'm definitely all in on initializing objects with a standard structure all in one go. (Acknowledging that there are likely to be cases where the structure isn't standard and it would be counter-productive to insist on a standard format.) I don't default to using options objects, that's for sure. I'm a pretty big believer in clearly named and specific parameters as they make your intentions clear at a glance: GetSum($table_pointer;$date_from;$date_to) Can be replaced by C_OBJECT($parameters_object) // Insert everything here GetSum($parameters_object) Ugh: GetSum($parameters_object) GetSum($table_pointer;$date_from;$date_to) #2 is a whole lot more informative in the code itself. For #1, you need to look at the rest of the method or, more often, see the object at runtime. (Often times information is flowing through a call chain and you might not see the object assignments right next to the object being passed down the chain.) I do like option objects for otherwise nasty code like this: MyMedioreMethod(->[Table];5;Current date;"";"";0;5) There are four optional parameters and only the last one is used - it's set to 5. In this case, an options object is nice for a couple of reasons: -- You only have to assign the value that you're interested in. -- Under some conditions, the called routine can distinguish between options that have been supplied and options that have not. With a fixed parameter list, that's harder. Does that all make you hate me less? ;-) I'll tell you one thing I hate, those absurd and massive "parameter" objects that are all-too common in JavaScript. I mean, they can get just insanely large. Completely out of control...and odd in a language with a very nice (as far as I can tell) closure implementation. Closures are probably the thing that I like the most in JS (at this point...not far enough along to say I won't find something I like even more.) ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
