> > So, I'd be happy to make everything an object under three conditions:
> >
> > 1) it doesn't interfere with *optimized* language constructs for
> > the most common tasks
> >
> > 2) it isn't being put in just to satisfy some theory that making
> > everything an object will make everything easier
> >
> > 3) it doesn't slow things down for those of us who want to use the
> > optimized interfaces and not worry about objects until we get to
> > 500-line programs
>
> Sounds like a fine set of constraints to add to the RFC.
>
> As far as (2) is concerned, certainly nobody who likes perl thinks
> that making everything an object will make _everything_ easier. But
> I think we proponents of this RFC believe it may well make _some_
> things easier, with the implementation of perl6 being among them.
I completely echo every sentiment of both Randal's and Bennett's points.
Some ideas that could be used to implement something like this can be
found in RFC's 49, 159, 200, 319, and 73 (best read in that order).
These RFC's are not hinged on 161, but if embedded objects were
attempted these mechanisms together could potentially implement them
(but they work fine without it too).
If objects were embedded, then filehandles wouldn't have to be "weird"
types. They could just be objects with class methods, which could be
inherited from and extended natively. But you still wouldn't care
because
print $STDERR @data;
would just work.
But none of this at the expense of speed; we need to keep the main goal
of a 10% speed improvement in mind. Speed wins over OO flexibility.
-Nate
