Well
pobocks, you're right, I guess having eyes attached to legs is not the best example. But basically I was just trying to exemplify the adding of parts to a body, then accessing those parts in any order with a single
$body object instance. The package
SOAP::Lite is a perfect example of stacking calls, even though I seldom use that kind of design.
stvn, I think "subclasses" could be the right word, given eyes are a body-part and inherit the 'blood pressure' attribute from the body, even though they could be implemented as inner classes as well. But definitely currying is not what I meant, so I take it back. Anyway, I came to this question while prototyping proof-of-concept code in Moose, starting with object usage in the final code and a simple does-it all class. I was researching a way to represent a DOM-like objects quickly without so many subtypes and with as little keystrokes as possible. I didn't know yet where all the pieces would fall, so I might write the eyes code before I have a head or a leg for that matter.
So this is not about my app design, which I've just started. It's that I really enjoy brainstorming with Moose, so after writing up around 20 lines of candidate has attributes, I saw myself writing another 20 arounds and, as a lazy programmer that I am, I was asking myself if I was missing something, on the lines of:
has 'eyes' => ( is=>'rw', chained=>1, ... );
## or
has 'eyes' => ( is=>'rw', isa=>'Chained[HashRef]' );
I'm glad to hear the Moose team is looking into that. At the end of the road, I'm just trying to replace my old style of prototyping with a big & ugly
sub AUTOLOAD { ... } directive with something a little more readable and extensible, just in case the prototype prospers.