Matt Youell wrote:
>
> > Great. My point I was trying to drive at was that:
> >
> > my int $x = 5;
> >
> > Could turn around and do something different than asInt(). All stores
>
> Got it. And sure, why not? Pay the overhead when you absolutely need to, and
> no sooner. The core idea (for me) is to avoid wasting resources on a
> meta-type if you don't need to.
We're in agreement I think, just edging around the same idea. My point
was that STORE, FETCH, etc would be the names of the internal core
methods used. Following RFC 168, "Built-in functions should be
functions", these could be completely overrideable. And if you overrode
them then you'd pay the penalty, like you said. So I guess my nitpicking
was really on the method names and exact implementation.
Did you see Dan's post? If they put vtable stuff in core, then this
means everything could be an object by default, just what we're looking
for :-). So stuff like:
my Dog $spot;
Would invoke $spot as a member of class Dog, and automatically inherit
the STORE, FETCH, etc methods from Dog, or default ones from CORE (or
SUPER). So you could define class Dog as:
package Dog;
# inherit STORE from CORE
# inherit FETCH from CORE
sub NUMBER {
die "Dogs aren't numbers!";
}
sub STRING {
return "bark, bark!";
}
# inherit all other stuff from CORE
And you would pay the penalty on STRING and NUMBER, but would get the
automatic speed of CORE's builtin STORE and FETCH, which would be highly
optimized.
Then, this approach can easily be extended to other vars as well:
my $name = "Nate"; # default CORE var class
my int $n = 5; # special class 'int'
my string $z = "A"; # special class 'string'
Bingo! All you're doing is invoking members of specific classes, which
override the appropriate CORE methods to create a unique data type.
Anyways, we should probably table some of this discussion until later,
since it hinges on alot of stuff internals is currently hashing out. But
I think more details like this should eventually be put in the RFC,
because it helps solidify the idea and give a little more structure to
it.
-Nate
P.S. Please no more mixedJavaCase methods, I'm starting to feel sick...
;-)
