Re: Mutator chaining considered harmful

You've sold me on it. I wasn't able to read a single example and know which ones were merely repeated method calls to the same object and which were successively deeper objects. In fact, I know that all the SOAP examples come with cascaded method calls but I never knew that in reality it wasn't just some deeply nested object being worked with. I always thought that, actually. That's because all the examples used the syntax for working with deep objects - ala A->B->C->D.

If you can write code that looks really damn legible and still completely throw me on what it means, its a bad idea. There isn't anything I can do to distinguish chained self-returning methods and chained successivly deeper object returning methods. This is just entirely bad practice because it is unreadable. If a person really means to call multiple methods against the same object, there are nice functional ways to do this that don't look like something else. multiple method calls against the same object, revisited has perfectly reasonable syntax to support this desire and it isn't going to be completely obfuscatory. Given my opinions on this, I think a programmer would have to be irresponsible to use chained self-returning method calls.

my $window = call_on_obj(
    Gtk2::Window->new( "toplevel" ),
    [ signal_connect   => ( delete_event => sub { Gtk2->main_quit } ) 
+],
    [ set_title        => "Test" ],
    [ set_border_width => 15 ],
    [ add              => call_on_obj(
        Gtk2::Button->new( "Quit" ),
        [ signal_connect => ( clicked => sub { Gtk2->main_quit } ) ],
    ) ],
    [ 'show_all' ],
);
[download]

Comment on Re: Mutator chaining considered harmful Download Code

Replies are listed 'Best First'.
Re^2: Mutator chaining considered harmful by Aristotle (Chancellor) on Dec 29, 2004 at 19:30 UTC
~~Heh. Spare yourself the sarcasm, I haven't used that in real code yet and don't intend to either.~~ Sorry — I really thought this was dripping sarcasm. It has led me to see a pattern which should have been obvious in retrospect, though. Please see my update on the root node. Makeshifts last the longest.	[reply]
Re^3: Mutator chaining considered harmful by diotalevi (Canon) on Dec 29, 2004 at 20:40 UTC
I wasn't being sarcastic about using the call_onobj function. I wouldn't have written that specific set of function calls because I don't use Gtk2. I used something similar in some code just yesterday. This is off the top of my head and I didn't use your specific function but it did the same sort of thing. In my case I'm effectively generating my functions and parameters by parsing a file and returning a list of events and parameters for them. It so happens that the general technique of writing your function calls as data is really convenient when parsing stuff. I can take one pass over the data to get my list of events and then just execute the events as code. `call_onobj( $renderer, [ 'UseFont', 0 ], [ 'SetDots', 52 ], [ 'SetScanLines', 300 ], [ 'AdjustDots', 15 ], [ 'AdjustScanLines', 2 ], [ 'Text', 'This is some text to be added to the output ] );` [download] The original query was on a series of hardcoded method calls all onto the same object. This is more general because now the method calls are mutable as data. It benefits two ways - by being more powerful and by not being a mimic for an unrelated sort of thing. I read `$obj->UseFont( 0 )->SetDots( 52 )->SetScanLines( 300 )->AdjustDots( 15 )->AdjustScanLines( 2 )->Text( '...' )` as more likely to be a deep object access than anything else. In general, I suspect that I will continue to be surprised when someone writes the preceding and they are all really just successive method calls on the $obj object. I grant that some uses of whitespace can make the chained-self intent more visible to someone who expects that. I don't think it helps anyone who didn't already have this technique in mind. I also think that no only I not be helped, that I will be hindered. The technique with this syntax is a dead end in perl5 and I would like it for people to write concise, clear code without it.	[reply] [d/l] [select]


P is for Practical
	PerlMonks