You're right, it's not full blown OO -- and that is a fault with my shortened constructor. I realized this last night when I realized my shortened constructors had pretty much lost that loving feeling (i.e. probably made inheritance about useless). Any suggestions about how to make HashesThatCanDoStuff a little more flexible?
Aside: I'm not really going for HashesThatCanDoStuff at all, I'm after named parameters, and the data structures would have been, most likely, used to implement Composites via named parameters. After all, a hash is a hash, but what you put in it makes it special :)
| [reply] |
What do you mean by "named parameters"? "Composites"? "named parameters", to me, are a way of passing information to a function. It doesn't have much to do with OO, specifically.
I would look at the problem differently.
- What system are you trying to model?
- What are the things that do stuff in that system?
- What is the minimal set of actions that each thing needs to be able to do?
- How will those things interact?
Once you know those things, then you can start working out what attributes each class needs to have in order to fulfill its requirements. Then, and only then, can you figure out where that information needs to come from. You may find out that most of it shouldn't come from the client at all!
Now, to answer the question "How do I pass attribute/value pairs to a constructor?" ... your very short constructor is actually the canonical (if non-resilient) way of doing it. *shrugs* Personally, I'd never use that outside of golf, but that's just me. There's CPAN code you use every day that uses that (or similarly terse) constructs. Heck, CGI doesn't even use strict!
------
We are the carpenters and bricklayers of the Information Age.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] |
Ok, I'll make up an example to explain why I'd like named parameters...pardon syntax errors, this is all untested. There *will* be syntax errors. Also, please don't study my problem space too much, as I'm just coding up a random example out of my head. I'm not actually coding a Chess program -- it's a generic question. You should see, though, from this example that I am not going after "HashesThatDoStuff", exactly, but rather something else stylistically.
Rationale for named parameters -- One of the things I often don't like about OO sometimes is that parameter order matters. When folks put more than a few methods in a constructor, it's rarely obvious which is which. So named parameters (as in, say, Python? Others?) allow the code to be a bit more readable.
my $board = ChessBoard->new('start');
my $game = GameState->new(
-white => ChessPlayer->new(
-board => $board,
-controller => Human->new(
-name => 'Larry',
-coffee => 1,
),
),
-black => ChessPlayer->new(
-board => $board,
-controller => Computer->new(
-level => 5,
-ply => 3,
-timecap => 60,
-style => 'Nimzovitch',
),
),
-board => $board,
-rules => new ChessRules('suicide'),
);
In the above example, timecap, ply, and level are all numbers, but I can easily tell them apart by the names, without having to know the order of the parameters as required. If I get the order wrong, it won't matter.
I'll admit the example above is contrived (I wouldn't normally construct my entire object model in one statement), but it shows what I'm getting at.
My OP question was, essentially, what are better ways to implement the above goal in Perl? How can we do this without creating mammoth constructors, yet still support inheritance and so on? MethodMaker will go a ways to keeping from writing accessor boilerplate and variable declarations, but constructors...that's the hardest part to keep elegant.
Thanks to everyone for the help and insight though. This is very good help for someone who is experienced in OO but still not quite getting it to come out elegantly in Perl. Appreciate it.
| [reply]
[d/l] |
