Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

How to learn a language - do stupid things 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'm afraid I'm on the "chained setters are stupid" side of things. What exactly are you accomplishing? Mostly, folks who think it's cool seem to be rationalizing an attempt to fit more junk on one line. There's nothing intuitive about it and it's probably just going to cause confusion down the road.
    • So, if you can code real fast this way, does that make you a chain smoker?

      It might be nice to have a syntax that factored out the object from a sequence of method calls to the same object. Something like:

      (@return list) = $object-->>(
                            -> meth1(args),
                            -> meth2(other args),
                         

    • What I'm accomplishing is grouping things together that logically belong together. Plenty of times I've seen cut-n-drool programmers slap some code in the middle of a chunk that shouldn't be split up only to break things and scratch their heads trying to figure out why. This makes it tougher to do that.

      No offense, but I don't buy the "confusion down the road" argument. Why is this confusing? Because it's new? No one has a problem chaining accessors and they do it every day in Java. The first time I saw chained mutators, I saw what was going on and thought that it was a nice tool. Accessors return different objects and mutators return this. It's pretty straighforward.

      As for whether or not it's intuitive, there is very little in any language (computer or spoken) that's intuitive. I can't tell you how many times I've read in computer books something along the lines of "ternary (or unary) operators confuse some programmers so you may want to avoid them". That's FUD. Would you really want to hire someone who thinks that ++variable is confusing? If you want confusing, consider context in Perl. Many of the rules seem arbitrary and are merely a matter of rote memorization. That's confusing. "Mutators return the object" is the only thing that needs to be remembered with chained mutators. That's simple.

      When I was doing mainframe programming, there was a huge section in our programming standards manual about COBOL keywords we weren't allowed to use because they weren't often used. That's just a silly self-fulfilling prophecy and I have first hand experience fixing stupid bugs caused by the contortions some programmers went through just to avoid some of those keywords.

      So restating all of this: the pro (to me) is that logically grouped constructs are distinctive. If I'm refactoring or debugging some code, it's immediately apparent that a chained mutator construct is a logical group that probably shouldn't be split up. This, like indenting to show scope, is not strictly necessary, but is very convenient for a quick visual understanding of the code (and when I first went from BASIC to C back in the 80s, I didn't grok indentation, either). I think that anything that improves visual comprehension of code is a good thing.

      So what are the cons? I hear some arguments against this in Perl and those arguments go both ways. Much of those arguments, however, struggle with Perl's lack of structured exceptions. That argument goes away with Java. As for being unintuitive or confusing, most who come from procedural languages would argue that about the signature of the main() function in Java programs (public static void main(String[] args)????). It's merely a matter of learning it.

      Now if you can point to real problems with this syntax, I'd love to hear them -- that's why I posted :)

      • The main problem with chained mutators is that it requires cooperation of all the mutators to work properly. It adds extra complexity to all of the mutator implementation to gain a little convenience for the caller.

        Also, sometimes it makes sense for mutators to return something. For example, returning the previous value can be useful. Or if the mutator constructs an internal object, then returning that object might make sense. In Perl, the lack of exceptions frequently means returning error indicator

        • It adds extra complexity to all of the mutator implementation to gain a little convenience for the caller.

          Surely that's a good thing! When you make it easy for the implementor at the expense of the user, you end up with something like Ant [apache.org] where you have to write XML. I'd much rather use Module::Build or even ExtUtils::MakeMaker for all their faults (and the former has many fewer faults than the latter), they're easier to use than either writing my own Makefile or writing an XML file.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.