> On Tuesday 13 Jan 2004 3:04 pm, James Edward Gray II wrote:
> > On Jan 13, 2004, at 6:24 AM, Gary Stainburn wrote:
<snip>
>
> I could reverse the parameter sequence so that the block type is
first, then
> allow multiple block names to be specified, thus reducing the work
involved.
> I'll probably make it so that it creates the links between the blocks too.
>
<big snip>
THis is the one point that I was going to remark on earlier. As your
system and objects, etc. become more complex there is a good chance you
are going to find that using a flat list as method parameter passing is
a nightmare, you may want to consider passing arguments in a named list
manner, so that they can be unordered, optional, etc. This adds to the
complexity of argument verification but in the long run adds flexibility
to the interface. Some examples:
my $object = new Class ("value 1", "value 2", "value 3");
In the above the new constructor takes three values that *must* be in
the proper order (unless their type can be gleaned in other ways such as
with ref or isa) and must all exist. For instance if you didn't need nor
have 'value 2' you still must specify a place holder, like:
my $object = new Class ("value 1", undef, "value 3");
etc. Which makes the interface less flexible in the future, and harder
to remember how it may(must) be used. I tend to advocate named
parameter passing such as,
my $object = new Class (key1 => "value 1", key2 => "value 2", key3 =>
"value 3");
Then when "value 2" is needed or isn't known simply drop the key/value
pair and nothing else in the method should need changing, assuming it
wasn't required before.
Certainly there are times when an interface needs to be simple and isn't
likely to expand greatly, or a particular argument must *always* be
provided, in which case this may be overkill but I thought I would
mention it. Using named parameters may also make it easier to pass
lists, which need to be passed as references, in which case explicitly
naming them may help on both sides of the interface.
As a side note to the list, I posted a message to Gary (trying to
prevent the previous thread from becoming cluttered, which it has now
anyways :-)) stating that I think his application (aside from the "real
time" need) is perfectly suited for experiments into POE. The
description of the system's needs jive exactly with what POE was meant
to handle...
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>