Tom Christiansen wrote:
>
> I happen to strongly appreciate that the invocant in
>
> $a->blah
>
> can be of either sort; that is:
>
> $a = "MyClass";
> $a->blah;
>
> or
>
> $a = MyClass->generate();
> $a->blah();
>
> In fact, who knows what generate() returned? It could have
> been a class name.
>
> There is beauty and power in this transparency, which you would see
> obliterated. I don't understand that.
Ooh, somebody else to bug about this! And the best example of where this
is really useful that I've seen.
I want to be able to get rid of STRING-> dereferencing with a pragma,
for type inferencing purposes. Specifically, $x = $a->blah() requires
"value inference" on $a, which is impossible in general though perhaps
adding all known class names as separate types to the type system will
make it possible some of the time. So I'm trying to collect examples of
where symbolic dereferencing is useful in order to figure out how best
to fence it off and keep it away from those poor sheep.
MyClass->f() is not a problem, of course. How often is nonref $a->f()
useful, and when it is, would
C<my $a : constraint($a->isa('MyClass') including string values of $a)>
ignoring the syntax, be acceptable if you want type-related warnings and
optimizations? (It's still not as good as requiring $a to be a
reference, because concrete type inference will produce the set of
actual subtypes that $a might hold, which may be able to eliminate
virtual dispatch unlike my MyClass $a or somesuch that allows any
subclass. But it's far better than allowing any subroutine named f to be
called, especially with AUTOLOAD lurking.)
And what other uses of symbolic references could you not live without in
a large application where you care about type warnings and type-based
optimizations? (I don't think anyone will want types in one-liners.)
Thanks!
