Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

OO semantics quandary

by belg4mit (Prior)
on Aug 14, 2002 at 18:36 UTC ( [id://190184]=perlquestion: print w/replies, xml ) Need Help??

belg4mit has asked for the wisdom of the Perl Monks concerning the following question:

Okay I have a preexisting class Foo::Bar. I am adding some new thingy that does not inherit from Foo::Bar, but is related, so how do I name it?
Foo::Bar::Quux
But then the existing object should probably be Foo::Bar::Baz, and I do not wish to break legacy support...
Foo::Bar w/ newQuux as a constructor
But then shouldn't the constructor for be newBaz?
Foo::Bar new(-Quux)
In a manner of speaking the current constructor is new(-Baz). However is having a single constructor returning multiple objects (well, Quux is a closure, but whatever) a faux pas? And then there's the semantics of new(-Baz, -Quux); return a list either in the order specified or always Baz then Quux? scalar context?
Never return Quux
Keep a global lookup table, and -Quux needs to be defined defined in both the new and Wiffle methods. This doesn't means more work to allow the destruction of Quux. And it goes against the rest of the design a bit (lookup table vs. OO). It's also then, less obvious that you can mix and match or even chain (chaining becomes semantically difficult) your Quuxes. eg;
$Quux = ... $Quuux = ... $Baz = ... $baz->Wiffle($Quux->($Quuux->("Hello World"))); $baz->Wiffle($Quuux->($Quux->("Hello World")));

Thoughts? Alternatives? I'm kind of leaning towards the thirdform.

PS> For the "terminally curious": Foo=>'Text', Bar=>'FIGlet', Quux=>'Control', Baz=>'Font'

--
perl -pew "s/\b;([mnst])/'$1/g"

Replies are listed 'Best First'.
Re: OO semantics quandary
by perrin (Chancellor) on Aug 14, 2002 at 18:56 UTC
    Your first example seems the most natural to me. Remember, package names are about organization, not about inheritance.

    As for whether to rename your existing class, only you can decide whether the value of the refactoring outweighs the value of legacy support.

      Yes, it was my initial inclination, and then I started thinking...

      --
      perl -pew "s/\b;([mnst])/'$1/g"

Re: OO semantics quandary
by pdcawley (Hermit) on Aug 15, 2002 at 05:13 UTC
    Rename Foo::Bar to Text::Figlet::Font. Create a class, Text::Figlet::Control. 'Text::Figlet' is just a namespace; it doesn't and shouldn't say anything about inheritance.

    Now, assuming you've been a good boy and don't have any code that actually uses an object's class name for anything, you're almost home and dry. Just add a factory method to Text::Figlet. Something like the following

    package Text::Figlet; use Text::Figlet::Font; use Text::Figlet::Control; sub new { my $proto = new; my $class = 'Font'; if ($_[0] =~ /Font|Control/i) { $class = ucfirst(shift); } $class = "Text::Figlet::$class"; $class->new(@_); }
    There's an issue here with having to update the factory every time you add a class, but it could be worse. Hopefully by doing it this way none of your old code will break.

    Also, bless that closure into a class, and give it a single method that calls the closure. Again, stuff that assumes it's a closure won't break, but you'll be able to add potentially useful methods without having to mess too much with the internals of the closure.

      This sounds reasonable to me but ofcourse, it's up to us to provide suggestions guidance, and it's up to the author to decide whether a suggestion fits right with their code. So, belg4mit, let us know what you think.
Re: OO semantics quandary
by dws (Chancellor) on Aug 14, 2002 at 18:52 UTC
    Okay I have a preexisting class Foo::Bar. I am adding some new thingy that does not inherit from Foo::Bar, but is related, so how do I name it?

    Depending on how it's related, how about Foo::Quux?

    I'm confused about the remaining alternative you list. It seems like you're dealing with some constraints (real or imagined) that aren't shown.

      The entire lists consists of possible naming alternatives, and the consequences/drawback/bonuses I envisage for each. Everything is in fact shown... well except one thing, see my (forthcoming) reply to smalhotra.

      --
      perl -pew "s/\b;([mnst])/'$1/g"

Re: OO semantics quandary
by dpuu (Chaplain) on Aug 14, 2002 at 21:12 UTC
    I'm sensing a factory here (factories make things).

    If you have Foo::Baz and Foo:Quux and ..., then you may want to create a Foo::Factory, which has the new method. (this could be your Foo::Bar)

    In perl, it seems quite reasonable to name the factory "new" and to pass parameters that control what is created. Languages like Java or C++ wouldn't like it; but this is Perl! (its best, though, if all the different things that your factory method creates all share a common interface) --Dave

Re: OO semantics quandary
by smalhotra (Scribe) on Aug 14, 2002 at 19:10 UTC
    In my opinion it depends on how related the modules are and how they are 'use'd. When you say 'thingy', I assume you mean module/object. If Foo::Bar uses uses Quux for implementing certain methods Foo::Bar without any inheritance, then you could have Foo::Bar::Quux.

    However, if Foo::Bar are related as in they both apply to Foo but not directly to each other, they I would suggest using Foo::Quux. (OT: anyone know how to pronounce quux?)

    Foo::Bar new(-Quux): I don't like this because it appears that quux is separate from bar and should therefore be in a separate module altogether.

    <code></ramble>

      They are related in that actually both provide a subset of the functionality of figlet(6). I say "thingy" because the second is not an object, but rather a closure.

      Foo::Quux is not an option (Text::Control is both non-sensical, and relatively useless. Quux essentially provides for specifying a series of tr transformations in a non-perl, plain-text manner. See "CONTROL FILES".

      I am still leaning towards Foo::Bar->new(-Quux), since as I said the Current Foo::Bar is really Foo::Bar->new(-Baz), and simply croak-ing on a new with both -Quux and -Baz.

      OT: I pronounce it qu-ucks, like quick ducks without the ick'd. This is in agrrement with The Jargon File, especially given the association with crux.

      --
      perl -pew "s/\b;([mnst])/'$1/g"

        OT: anyone know how to pronounce quux?

      I tend to pronounce it "kooks", like the Usenet infestation, but I think "kwooks" is more popular.

      --
      F o x t r o t U n i f o r m
      Found a typo in this node? /msg me
      The hell with paco, vote for Erudil!

        I pronounce it kwuhks; rhyming with bucks rather than books (or pukes). I think that is generally accepted.

        I pronounce "qux" as kuhks and "quuux" as kwew-uks but I think those are both personal variations.

        -sauoq
        "My two cents aren't worth a dime.";
        
        The Jargon File entry for "quux" claims that it is pronounced /kwuhks/.

        -- Mike

        --
        just,my${.02}

Re: OO semantics quandary
by belg4mit (Prior) on Aug 19, 2004 at 14:28 UTC
    Well, I still haven't released this revision :-/ but I ended up with (years ago)
    sub new { local $_; my $proto = shift; my($class, @isect, %count); my %class = ( -f => 'Font', -C => 'Control' ); $count{$_}++ for (keys %{ {@_} }, keys %class); $count{$_} == 2 && push(@isect, $_) for keys %count; croak("Cannot new both -C and -f") if scalar @isect > 1; $class = shift(@isect) || '-f'; $class = 'Text::FIGlet::' . $class{$class}; $class->new(@_); }

    --
    I'm not belgian but I play one on TV.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://190184]
Approved by aufrank
Front-paged by aufrank
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2024-03-29 06:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found