Like everybody, I tend to develop habits/patterns/templates for my methods. There are lots of benefits to consisincy:
-- If it worked before, it will work again. -- It's a lot faster to do what you know rather than thinking everything through from scratch each time. -- Old methods look totally understandable, even after a long time. So, I tend to name things pretty consitently, organize my methods in a couple of basic ways and handle parameters in a particlar way. But it's good to revisit old choices now and then and see if there's a better way. Not long ago, I was reading some materials arguing aginst optional parmeters. Not much after that, Rob Laveaux made a comment (paraphrasing here) about initializing objects with *all* elements. In ther words, create a C_OBJECT and populate it with all elements right away (even if blank or default values) so that the rest of your code never has to worry if the element exists or not. It does. All of this got me thinking about these similar subjects: optional method parameters and optional object elements. I thought I'd toss out a few words and see what other people think and might offer. I'm in that brief period when I'm being open minded about something. Soon I'll make some deciscions, and then I'll probably stick with them for a few years. (Like most people, I'm right all the time...but what I think is right does change down the years. Earlier David Adams? What an idiot. Now I'm finally right...) Anyway, I like explicit parameters, so I'm not down with pushing everything into an object - I'm definitely not trying to start that discussion. But I do tend to keep param lists short. Here's an imaginary example of a method that takes 2-3 parameters: MyWonderfulMethod(->[Table]Foo;5) MyWonderfulMethod(->[Table]Foo;5;Current date) $3 is optional: $table_pointer:=$1 $day_count:=$2 If (count parameters>=3) $date:=$3 Else $date:=Current date End if I set this kind of code up *automatically*. I find that I'm going it for methods that are only called from one or two places. Why? It makes no sense. Somewhere down the line something in me decided that every parameter made my life worse in some big way that was worth a lot of effort to avoid. So it's been my custom to make as many parameters optional as possible. Looking back, I think I made a mistake. Yes, it makes it easier to call a method if there are fewer parameters, but how much easier? Well, when there are only a few parameters, it's not really much of a gain. For long parameter lists, sure...but if I've got 6+ parameters, I might want to take another look at how I'm setting up the code. Okay, now what about the *costs* of optional parameters? There are several: -- The code inside the method is more complex, both for assignments and testing -- The code is harder to read and rewrite because it's more complex -- It's harder to scan for missing parameters. So I'm being bold and making more explicit parameters and fewer optional ones. With that said, sometimes I've ended up with optional parameters because a routine has various options. In that case, it is pretty nice to have an options object: C_OBJECT($options_object) $options_object:=MakeMyWonderfulOptionsObject OB SET($options_object;"capitalize_words";True) MyWonderfulMethod(->[Table]Foo;5;Current date;$options_object) This can be really helpful when there are several options. Speaking of several options, back to Rob's point (or what I took from what he said anyway.) Yeah, I'm 100% down with creating the object with all elements defined. Leaving out situations where this makes no sense at all (you know who you are), it's a great way to move forward. You create a method to define your object (thinking of each C_OBJECT of this sort as a "type") and then you always know that the elements you need are in place. You can assign default values at the same time, which is handy. If you need to add/remove/rename elements, you know right where you go to do it. Also speaking of objects: Use custom constants for element names! For those of you with access to current tech notes, there's a newish one that I wrote up with Cannon Smith with lots of details and handy code from Cannon (so you know it's good) to manage constants entirely within code. Jim Dorrance has also kindly posted custom constants code here in the past, so that's in the archives. Kirk Brooks often mentions using custom constants for his element names, so he may have a few thoughts too. Managing Custom Constants with Code http://kb.4d.com/assetid=77806 Anyway, back to objects...as many of you know from you're work, they're quite handy for storing data that is used through multiple methods to complete a task. Done right, this can greatly reduce parameter list lengths without compromising the ability to test your code and without necessarily adding undue complexity to your methods. So, open to thoughts and suggestions...but only briefly ;-) ********************************************************************** 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:[email protected] **********************************************************************
