Nathan Torkington wrote:
> 
> Are you proposing making even "normal" scalar, hash, and array access
> go through these methods?  Wouldn't that slow everything way down?

Glad you brought this up, Nat!

I would say "yes and no". The reason I'd say this is because Dan S. and
the internals guys are doing a lot of interesting stuff down these
lines. I would also note say that if we had *one* single scalar data
representation, this could be even FASTER than currently, because
everything would be the same.

That being said, you are right in that if this was stuck on top of Perl
5, things would be so ridiculously, terribly slow as to be unusable. If
that looks like it's still going to be the case with Perl 6, then I'll
be the first to drop the idea.
 
> It's like you're proposing an extension to the current tie system to
> deal with more operators, and then saying "no variable can have a
> value, they all have to be ties to objects".  Is that what you're
> suggesting?

Basically, yeah. Sort of. Maybe. I hate putting the word "tie" in there
anywhere, because my goal would be to make default Perl flexible enough
that tie() could be dropped altogether.

In my "vision" (disclaimer: just because it's a vision doesn't mean it's
a GOOD one), Perl 6 is a world where objects are embedded at the lowest
level. You can define specialized accessors methods, like those defined
in RFC 159, to override the default behaviors. If you don't provide
these methods, default ones are provided for you out of CORE.

So, everything is passed around as an object - albeit most of them are
extremely lightweight objects, with only one or two methods and a
single, simple value (like "5"). However, with one common data
representation, there is an amazing amount of consistency, no more
OO-slapped-on-as-an-afterthought, etc.

Remember: All this assumes it's feasible internally. If not, it gets
dropped. But I'd rather work out the kinks of the idea, give it to Larry
and the internals guys, then have them say "What are you, nuts?".
Because if we're not nuts, this would be really cool...

-Nate

Reply via email to