Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: chaining method calls

by adrianh (Chancellor)
on Jun 11, 2003 at 23:20 UTC ( #265221=note: print w/replies, xml ) Need Help??

in reply to chaining method calls

I'm in the "love it" camp :-)

It reads well to me. I just read "->" as "and then call method" and it makes perfect sense. It's compact, which is good in my book since it allows me to get more "useful" text on my screen when I'm coding.

Never had problems debugging it myself.

It's also similar to the normal Smalltalk idiom so people with that sort of background will find it natural.

Replies are listed 'Best First'.
Re: Re: chaining method calls
by halley (Prior) on Jun 12, 2003 at 13:08 UTC

    This is an important point on idiom, and since idiom is a matter of choice of expression, I won't weigh one way or the other, but will caution that Perl's ruthless lack of discipline, while a benefit in many cases, complicates things for those who prefer or need consistent design.

    In Perl, there's no difference between a "message" to an object and a "functor" answered by an object. Thus, obfuscation aside, they both have to use the same invocation syntax: $a->b().

    The following distinction is my own OO philosophy, sometimes consistent and sometimes inconsistent with others I've seen, but I think it's a very useful paradigm.

    Messages should be invoked for side-effects, and should have no immediate return value, so that (1) they can be transaction-wrapped, (2) they never block the invoker, and (3) on some application architectures they can be posted onto a queue instead of handled immediately. If you stick to the "messages have no immediate return value" philosophy, then supporting it with a Perl return $self idiom makes sense.

    Functors should not have side-effects (other than local caching), and should have an immediate return value. Again, these benefits complement message handlers: (1) they can be seen as atomic, (2) thus they may need to block, and (3) in a remote architecture, a dumb stub can return cached values but can't actually decide anything behaviorwise.

    (Some people may think "ack! invoke for side effects which may not be done immediately?" If you must wait for a message transaction to be realized or verified, you wait with a functor that can block appropriately. Otherwise, you trust it will get done.)

    Unfortunately, you can't easily tell a Perl "functor" from a Perl "message handler." They're both just subs. They're both invoked with $a->b(). If nobody makes a mistake, messages can chain with $self, but yet functors can't. Tread carefully.

    [ e d @ h a l l e y . c c ]

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://265221]
[marto]: so I have to work Saturday, which is good and bad. Bad in the sense that I have to be hear early :( Good in that I am here only as support for another client project, so I get to spend the day working on my personal 'ToDo' list, without the kids :P
[Corion]: marto: Ooof - but yes, being there as only second level support or third level support is good and if you have enough things that you can work on, it won't be a wasted (if paid) day
[marto]: I've opted for a day off later on, rather than pay. I only have to do about 45 mins work for the client, but do need to hang around
[Corion]: marto: Even better ;)

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (7)
As of 2017-02-28 10:06 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (399 votes). Check out past polls.