Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

object aggregators

by mojotoad (Monsignor)
on Jun 12, 2003 at 20:15 UTC ( #265479=note: print w/replies, xml ) Need Help??

in reply to chaining method calls

I've used a related idiom in some of my modules -- namely, having a dispatch or aggregator object that operates on several objects simultaneously.

So rather than:

@parms = ...; foreach $obj (@objects) { $obj->duckwalk(@parms); }

I just say:


If you wonder why you'd ever want to do that, imagine manipulating an HTML::Element tree that represents a table like so:

# Manipulates multiple table cells $table->col(7)->attr('bgcolor','#BBFFBB');

So to answer your original question, I like the idiom. I consider it a degenerate case of what I illustrated above.


Replies are listed 'Best First'.
Re: object aggregators
by Revelation (Deacon) on Jun 14, 2003 at 22:09 UTC
    Your second example is interesting, but I wouldn't call it method chaining at all: Method chaining is a mechanism to change related attributes, which have very little effect on each other. Consider:
    $person->make_head('large') ->make_nose('small') ->make_belly('surgerized');
    This is method chaining. What you are doing (externally), however, is calling a method on the seventh column of a table. It is best achieved simply (IMHO) by returning a reference to an object of package column, whose methods you can call (your probably knew this, but I'd rather emphasize the point for other readers). Code would be something like:
    package Table; use Column; sub new { bless [],__PACKAGE__ } sub col { return $_[0]->[$_[1] + 1] if exists $_[0]->[$_[1] + 1]; $_[0]->make_column([$_[1] + 1]) and return $_[0]->[$_[1] + 1]; } sub make_column { $_[0]->[$_[1]] = Column->new; }
    Like you said, you're even doing that in your first example. You're just enapsulating a series of objects in a greater object. The method I use, though, would make it so that you don't have to even hold the differant objects. ( sub aggregate { $_->duckwalk($_[1]) for @{$_[0]}) } )

    There are no similarities between that and object chaining- you are not returning self; you are returning a different object...
    Aggregators are perfectly intuitive, because most methods return something. For aggregators that something returned is a different object, but that's no different from 5.squared returning 25, if you consider 5 and 25 to be objects of NUM or something like it (like they are in Ruby and other languages).

    However, method chaining is completely counterintuitive, because it's not natural to have $object->make_head('larger') return the object with the head made larger. One would expect it, like most methods, to return true on success and false on failure. This is the programming idiom that most programmers would subscribe too. If something is not returning true or false, then OO standards would dictate that it's returning another object, which will be modified. If you were to give me the same code I previously mentioned without telling me that you're employing method chaining, I'd ask you why you're modifying the belly of a nose. What is the belly of the nose?

    This point is hammered in by that notion. However, intuitively, my rejection of method chaining is that it doesn't make sense without the requisite white space. Programmers are almost forced to indent when they chain methods to show that all the methods are basically working off of the single parent object. When indentation is forced for a process so simple as changing an object you know there's a problem.
    Gyan Kapur

      However, method chaining is completely counterintuitive, because it's not natural to have $object->make_head('larger') return the object with the head made larger. One would expect it, like most methods, to return true on success and false on failure.

      Well, it does return true on success. And when you provide for method chaining you usually use exception handling and not inband error codes. As for indenting the chain, thats a matter of taste. All I know is that I sure am glad I can type:

      print Data::Dumper->new([$foo],[qw(foo)])->Indent(2)->Purity(2)->Dump( +);

      Instead of

      print do{my $d=Data::Dumper->new([$foo],[qw(foo)]); $d->Indent(2); $d- +>Purity(2); $d->Dump()};

      And any hard and fast rule that says I can't/shouldn't do the above I would reject as being utterly unworkable in practice.

      As I said elsewhere in this thread, the probable and common usage case should be the deciding factor in how a given method behaves. One shouldn't have to contort oneself to fit into some arbitrary coding scheme when there is no reason to. The Perl motto for things like this is that easy things should be easy and hard things possible. Selecting a method design that meets these requirements is the only design criteria as far as I am concerned.

      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...

Re: object aggregators
by Aristotle (Chancellor) on Jun 13, 2003 at 07:48 UTC
    That's a great idea. I've always liked the XPath syntax to identify a set of nodes in a tree - so much more elegant and concise than any kind of iteration.

    Makeshifts last the longest.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://265479]
[marto]: can I nominate users ? :P
[Discipulus]: AM will rulez!

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (11)
As of 2018-05-22 08:30 GMT
Find Nodes?
    Voting Booth?