Re: RFC: Package == class == object type

From: Wiggins D Anconia (wiggins_at_danconia.org)
Date: 01/13/04 

Date: Tue, 13 Jan 2004 10:05:13 -0700
To: Gary Stainburn <gary.stainburn@ringways.co.uk>,   Perl Beginners Mailing List <beginners@perl.org>

> 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

Relevant Pages

  • Re: RFC: Package == class == object type
    ... >> I could reverse the parameter sequence so that the block type is ... Which makes the interface less flexible in the future, ... > lists, which need to be passed as references, in which case explicitly ... The idea of named parameters is worth considering as my project and therefore ...
    (perl.beginners)
  • Re: Features that can only be provided by the implementation?
    ... specific behaviors of standard CL functions allow but not mandated ... such as an interface to sockets.) ... Built-in Functions ... Getopt Parameter lists ...
    (comp.lang.lisp)
  • GNU Gengetopt 2.22
    ... GNU Gengetopt generates a C function that uses getopt_long function ... (the user can specify those options manually) ... The following mailing lists are available: ...
    (gnu.announce)
  • Re: Stage Manager/Theatre Management Software
    ... > schedules, attendance lists, cue sheets, work note sheets, cast/crew ... > design, ... It could be extended easily to cover crew, tech, performances, ... Regarding the interface. ...
    (rec.arts.theatre.stagecraft)
  • Re: A taxonomy of types
    ... With this explanation OO (as seen in statically typed OO languages ... The static type defines the interface for the variables, ... objects (in the Seed7 philosophy really everything is an object), ... OCaml, which applies to lists of ints, lists of strings, etc.) and, say, ...
    (comp.lang.misc)