On Tuesday 13 Jan 2004 5:05 pm, Wiggins d Anconia wrote:
> > 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
Hi,
I've not responded to these two comments yet as my head was struggling enough
with the read of the thread.
I've looked at POE before, and at the time thought it looked far too
complicated. However, looking again now may produce a different opinion. I
still think that it will be a bit OTT for my project.
The idea of named parameters is worth considering as my project and therefore
the methods is starting to get far more comprehensive and complex.
Gary
--
Gary Stainburn
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
