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. | [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] [d/l] |
|
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.
| [reply] [Watch: Dir/Any] |
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.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
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 | [reply] [Watch: Dir/Any] |
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> | [reply] [Watch: Dir/Any] |
|
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"
| [reply] [Watch: Dir/Any] |
|
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!
| [reply] [Watch: Dir/Any] |
|
-sauoq
"My two cents aren't worth a dime.";
| [reply] [Watch: Dir/Any] |
|
The Jargon File entry for "quux" claims that it is pronounced /kwuhks/.
-- Mike
--
just,my${.02}
| [reply] [Watch: Dir/Any] |
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.
| [reply] [Watch: Dir/Any] [d/l] |