Matt Youell wrote:
>
> Originally I was trying to avoid explicit typing through new keywords, like
> 'int'. So the latter option would have been the case. But after Nathan
> Wiger's reply to my RFC, I realized that either syntax would work. Under one
> scenario, 'int', as in your example, would simply be the name of a factory
> function, so that:
>
> my int $intVal = 0;
>
> could be equivalent to:
>
> my $intVal = Scalar->int(0);
>
> And with no more typing required than before.
Matt-
I just want to hit this point a little more, to make sure we're actually
in agreement.
Under my RFC (which I have postponed assuming you and I see eye-to-eye),
'int' would be a special package (a subclass) and *NOT* a function:
package int;
# inherit all methods from CORE except:
sub STORE {
if ( is_not_an_int($_[0]) ) {
return ERROR_BAD_DATA_TYPE;
} else {
internally_store($_[0]);
}
}
Pardon the extreme pseudocode, but you get the idea. Then you'd write:
my int $x = 5; # $x->CREATE, $x->STORE(5) from class int
This integrates OO at the bottom level, but hides it where nobody can
see it. Inheritance is ridiculously simple - everything is some class or
other, and that class's methods are simply used to store and access
data. Everything is an object, only unlike Python (been reading a lot),
nobody has to know.
My idea would be to seamlessly integrate this idea with RFC 159. We'd
use the existing OO structure of Perl 5, only we wouldn't put it on top
of everything, but put everything on top of IT.
Sound good? If we don't agree 100%, that's fine, I'll just RFC mine
separately. Even if the idea is the same, if the procedure is markedly
different it probably deserves a separate RFC. But if we agree and
you're willing to change the language of your RFC to reflect the above
class structure, then fewer RFC's for Larry to have to read is probably
good. :-)
-Nate
