If you have to explain then it doesn't make sense. This is a little like Corion's How to best pass on the context / wantarray? issue: you have to know subtle stuff beyond the immediate context to understand the code. In fact, if you don't know that stuff you may get completely the wrong idea about what the code is doing.
In this case I'd be inclined to add a member to List that calculates the total for the list. Then The code explains itself:
my $total = $list->total ();
doesn't leave much room for ambiguity.
DWIM is Perl's answer to Gödel
| [reply] [d/l] |
That sounds a lot like diotalevi's idea.
Ok, maybe I am going for this approach.
| [reply] |
Your "is a" shouldn't be. By your description, a list isn't ever a number. You just want a to treat it like a sum. Then provide a ->sum property.
| [reply] |
Actually, you're right.
However, both List and Number are values (I aim for the Stating The Obvious Awards) on which a number of equivalent operations can be performedm such as add, substract, multiply, divide). Would it make sense to have a common superclass for List and Number then?
If yes, then let's assume this superclass is called Value.
Would I name the other classes Value::Number and Value::List, or do I just name the three classes Value, Number, and List?
| [reply] |
| [reply] |
No. You're being excessively generic. It isn't immediately obvious what "add" means in connection with a list. My first interpretation that "add" would be applied once to each element in the list and thus return a new list, transformed. That is, map() and +. So why are you reimplementing basic things like arrays anyway? Usually, if a person wanted a sum from a list they'd say it in an obvious way like sum( @bunch_o_numbers ) (List::Util::sum) or similar. This "Value" parent class or more commonly, "Object" is a common pitfall and never, really a good idea. That is, unless you're doing something gemane to http://lambda-the-ultimate.org. Then write the paper on it and publish it for all of us to read.
| [reply] [d/l] |
If this were a b&d language, you'd have both Number and NumberSet implement an interface
which simply defines one method returning the "current"/"total" numeric value.
Because this is Perl, you only need to have the two
classes implement that method, without any explicitly defined interface.
Then, in any situation where you'd call that method, as long as the object is of one
class or the other, you're good to go.
And certainly, from what you've told us, the two classes don't
need to be related in the class hierarchy at all.
We're building the house of the future together.
| [reply] |