Piers Cawley wrote:
>
> And the RFC then proceeds to ignore this point and proposes something
> that looks remarkably similar to the current overloading scenario. Or
> am I missing something? I really can't see where the win is with this
> proposition.
The win is that this allows us to embed objects at the lowest level
possible in Perl 6, make them appear to be just regular old scalars, and
nobody has to know the difference.
If you check out the thread starting here on RFC 161:
http://www.mail-archive.com/perl6-language-objects%40perl.org/msg00109.html
I think you'll understand more why this is so powerful and so cool.
The examples are intentionally simple just to avoid confusion. However,
the idea is to embed a tie-like interface in Perl 6 from the get-go. In
fact, we might not even need tie() anymore at all. But there are hooks
for you to overload stuff on an object-by-object basis, with *different
class methods*. For example:
package Dog;
# inherit STORE, FETCH, etc from CORE
sub NUMBER {
die "Can't use dogs in numeric contexts!"
}
package int;
# inherit STORE, FETCH, etc from CORE
sub NUMBER {
return self->VALUE; # or something
}
Then in your code:
my Dog $spot = "Rusty";
my int $x = 5;
$y = $x + $spot; # dies with "Can't use dogs in numeric contexts!"
While this example again sucks, you get the idea - we now have objects
embedded all over the place, and we're able to replace extremely complex
type checking with simple member methods. But from a *user* standpoint,
they don't know or have to care.
-Nate
