Luke Palmer wrote:
> I would imagine that would only work if $a was known at compile time:
I think we could do it at runtime too. You could conceivably use
runtime resolution to, for example, choose from between several
different caching behaviors to be passed to a complex routine:
sub get_cached_foo( HashImplementor $implementor ) { # syntax???
my %foo is $implementor;
...
return \%foo;
}
my $foo = &get_cached_foo( LRU_Cache );
That should be OK... we have to know what C<$implementor> is when we
actually do the C<my %foo>, but it doesn't have to be known at compiletime.
My only concern with this particular example:
my $a = MyCache; # (1) $a contains a class identifier
my %b is $a; # (2)
vs.
my $a = 'MyCache'; # (3) $a contains a string
my %b is $a; # (4)
is that 1-2 should work as intended, but 3-4 probably doesn't... because
in (3) $a is just a string, *not* a class. Since a string instance
doesn't implement the interface to be a Scalar implementor, (4) would
give a runtime error. So I *think* the first example should work, and
the second example should not.
> Actually, that's quite a difficult question; is MyScalar a
> property or a behavior class? Is there a difference, or is the latter
> a subset of the former?
Yeah. In the words of another cartoon character, "I *don't* know."
:-/
MikeL
