Re^2: A caller() by any other name

Indeed, dead right in one :-)

IMHO, extending (caller)[0] to return an instance (c/w a package) isn't a violation to the same degree since it would be incumbent on the called sub/method to use the information presented...the design problem, such as it is, is outlined in my OP - being the need to implement inter-class relationships (as defined in a class diagram), hence my suggested afterthought WRT a class to implement the relationship between the participating classes - thus...

Each participating class registers itself with the Relationship class - not knowing, or indeed needing to know, about the other class(es) in the relationship.
The Relationship class handles method invocations between the participating objects.

AFAICS, Re: Proper way to create 'globals' would only work for singleton/monadic classes - it would need some work to achieve the same end for classes having multiple instances.

A user level that continues to overstate my experience :-))

Comment on Re^2: A caller() by any other name Select or Download Code

Replies are listed 'Best First'.
Re^3: A caller() by any other name by JadeNB (Chaplain) on Dec 04, 2008 at 22:22 UTC
I'm not sure if I'm just reiterating kennethk's solution in the language of lexicals-in-closures rather than globals, but couldn't you do something like: Read more... (581 Bytes) UPDATE: On further thought, you could even confine the messiness of those `caller->caller` semantics to one place by defining a function like `sub called_by { return ( caller 1 )[0]->caller; }` [download]	[reply] [d/l] [select]