Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

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]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2018-03-19 18:48 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (246 votes). Check out past polls.