Obviosly all the method calls are targeted at the Person object (I mean a job does not have a wife, and we all know that Marge's favorite food is potatoes!) but other times I'll see things like the first line from work where it looks like each call is invoked on the last referenced object.

Does it depend on what each of those calls are returning? i.e. a return of undef forces Perl to make the call on the next previously defined object? Or is there some other rule that I am not aware of?

I have gone through the Object chapter of Programming Perl, 3rd Edition. Feel free to direct me within that text or on-line for an existing explanation. I may have just missed it as a result of my frustration.

where the result variables are temporary. In order for the code to work as expected, the methods (name, job, wife, fav_food) must return the original object. A sample method that works this way would look like this (assuming the object is a hash ref):

This code fragment will set the value and return the object if a value is given, else it will return what the name is set as.

So why do you sometimes see the original object ($Person in this case) have multiple method calls originating from the original obect on multiple lines? Because if the method returns a value other than itself (which is quite common), it will try to call the method on that value, and most likely fail.

In your first example, the assumption I would make based on what I see is that

$interface is a handle to an object that has a method, handler() that takes a parameter ($client) and returns an object.

This object is probably the handler object for the specified client for this interface.

This handler object has a method parse that takes a string, in this case probably a filename, and either parses that string, or possibly the contents of a file who's name is held in that string.

That the results of the parsing are not returned immediately suggests that the latter is more likely, and subsequent calls to the handler would be needed to verify and/or retrive thos results.

That no attempt is made to check any return code from the parse call would worry me slightly.

In the second example, the code looks remenicient of much of the Java Library API's, where accessor methods for 'set' operations return their own handle allowing calls to the 'set' methods to be chained.

So that $Person is the handle to an object that has (at least 4) private attributes (name,job,wife,favorite_food), and accessor methods that return (at least when a parameter os passed) their object handle, thus leading to the notational 'short-hand' of

Of course the real answer is that you shouldn't need to make these assumptions, as you should be able to consult the documentation, even if, in the worse-case scenario, the only documentation is the source code.

One of the joys of an interpreted language (interpreter/compiler debate aside) is that you always have the source to fall back on. None of the agony of trying to maintain and/or modify code that uses binary libararies for which the source and or documentation has long since disappeared or never existed in the first place.

In your first example:
$interface->handler($client)->parse($local_file_name);
the method that is called is the parse method of the object referenced by:
$interface->handler($client).
The arrow operator associates left to right, hence the above result.

seems to be just plain weird. I might be (and almost certainly am) missing something - the same thing as you in that case :) - but I read this as "execute the method fav_food on the object returned by executing wife on the object returned by executing job on the object returned by executing name on the thingy referenced in $person" (arguments left out to save what little shreds of clarity remaining). Beats me. Help.

You are right, it does appear to be plain weird. It should evaluate differently than The_Don expected, with the -> operators operating left to right, so you did read it correctly. BrowserUK made a note about the Java APIs working this way, perhaps name(),job(),wife(), and (presumably)fav_food() all return the object that called it, that much is not clear. Personally, when writing classes I tend to have my mutators (set()s) return nothing, making a clear distinction between accessors and mutators (except in certain circumstances).

Others have offered explanations and if you'd like another example (perhaps something a little less textbook-like) I just grepped this from my scratch directory. It's hideous, yes, but demonstrates the point at hand.

I'm assuming, of course, that HTTP::Request isn't going to fail (unlikely anyway). And this doesn't allow me the opportunity to do anything useful with the UserAgent object other than what I could have accomplished with LWP::Simple. I have no idea why this was there, other than to serve as an example of some kind. Whether this was to demonstrate something good or bad, I can no longer remember. :)

This mess is more commonly written as something like (edited from the LWP manpage):

So what my code snippet above did was exactly what's being done below, except that I don't put the request object into a variable ($req), and I don't put the user agent object ($ua) in one either. The only thing I stash away is the result ($res/$_) object because I have to call two methods (content, is_success) on it. Neither of these returns the original object, so I can't chain these together with ->'s.

I would again like to thank the Monastery for their responses. I have come to the final assumption that each call to the objects that set an attribute return the object; thus, 'set' calls can be chained.

The final answer, which is so simple I that I apparently ignored, is that the '->' is left associative. This behavior as best I can tell mimics Java completely and I understand completely (I was taught computer science using Java).

To address why I did not resort to source code for a definitive answer. The code that the system uses automatically creates accessor methods using a %fields hash. I do not have enough knowledge of existing modules to know where / how these accessors are automagically created nor if the auto-functions are a result of a CPAN module, an in-house module, or a hybrid. However, my past experience with the system has shown me that the level of extension with OO Perl reaches levels so deep and convoluded that it was a much better use of time to ask for assistance from strangers with no knowledge of the innner-workings than to seek assistance in-house.

Again, I would like to thank everyone for their help. ++ for everyone ! :-)