[LA.pm] Classes with heterogeneous objects?

[Mike MacKenzie]

You are right of course, ref wouldn't tell you the underlying implementation type.  However, I think Randall is still correct -- ubiquitous use of introspection code (aka navel gazing) is a real downer.  Encapsulating the type determination code in a lookup table/method somehow would help but you'd still have the overhead  -- actually more overhead computationally.

I suppose you could write multiple subclasses, one for each implementation type, and have the base class constructor act as a factory method.  But then you lose the 'specialness' of them all being
instances of the exact same class.

Mike


----- Original Message -----
From: Uri Guttman <uri at stemsystems.com>
To: Randal L. Schwartz <merlyn at stonehenge.com>
Cc: Mike MacKenzie <mackenziemikebus at yahoo.com>; Los Angeles Perl Mongers <losangeles-pm at pm.org>
Sent: Friday, March 2, 2012 9:27 PM
Subject: Re: [LA.pm] Classes with heterogeneous objects?

On 03/03/2012 12:06 AM, Randal L. Schwartz wrote:
>>>>>> "Mike" == Mike MacKenzie<mackenziemikebus at yahoo.com>  writes:
> 
> Mike>  Can any of you guys think of an interesting use case for a class
> Mike>  that creates objects with disparate internal structures like
> Mike>  this?   Or do you know of an existing module that does this?
> 
> The big problem would be the amount of sheer navel-gazing you'd need
> within the class to do anything like accessing the attributes.
> 
> Hint:  if you have to use "ref" a lot in your design, you lose.

and ref won't help as it will just return the class name on any blessed object regardless of the underlying type. reftype from scalar::util will do what you want. and a simple dispatch table keyed on the ref type would eliminate the need for many calls to reftype.

now as for a use case, i am stumped. some questions are best left unanswered. but i bet damian could find one if asked!

uri