At 07:55 AM 8/9/00 -0700, Nathan Wiger wrote:
> > It means a lot more code to write (and debug) for the things that
> > return these objects, and that means parts of perl will be
> > slower, take longer to write, and take up more space.
>
>Point taken. I don't think internals should be ignored altogether, just
>that they shouldn't be the driving force in the language design.
>Otherwise we'd wind up with something like C. :-)
I do agree that the internals shouldn't drive the language (otherwise a
crack team of Ninja would've already taken care of that Conway guy... :),
but neither can they be completely ignored. I'm just weighing in with a
rough estimate of the cost. It's someone else's job to balance that cost
with the benefits, but that can't be done without at least some idea of the
cost. (I expect Larry's got a good handle on that already, or will when he
takes a hard look at the final proposal, but...)
>One alternative is to add a pragma to implement this, maybe called
>'object'. So a person could 'use object' to get the objects flowing
>everywhere. But again, this is an implementation thing I'd rather save
>until at least v2, after people have given input on the idea itself.
Honestly, I'd rather you put together a general scheme for handling the
object/scalar morphing thingie and RFC it, and then we migrate the various
functions that people think should do the object thing as time and effort
allow. They all might not be in perl 6.0.0 (And what are we going to call
the first dev release--perl 6.-1.0?) but could get added in as modules and
make it into perl 6.2.0 or something)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
