I don't think it will be a half million objects.
Let's take stat (and all the other long list returns). The underlying
implementation object could be a packed structure psuedohash. (Think
DSECT.) Then the only op would be the packed structure pseudohash
lookup. Which would be done at compile time. (Fallbacks to the hash
lookup if really generic.)
For the other types, it would be quite invisible. The parser would
translate the $foo->SCALAR into whatever you would want scalar($foo)
to have returned.
Similarly for other possible constructs. Just think of it as moving
the internal access routines closer to the language.
<chaim>
>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> On 9 Aug 2000, Perl6 RFC Librarian wrote:
>> =head1 TITLE
>>
>> All Perl core functions should return objects
DS> While an interesting idea, it'll mean we have a half-bazillion different
DS> types of objects floating around just from the core. The number of
DS> different vtables needed to deal with this (along with the functions in
DS> those tables) is rather formidable, and it will tend to impact
DS> performance. (The more different pieces of code you have the less cache
DS> coherency, which means things go slower)
DS> These really aren't objects anyway, they'd be magic scalars. (And yes, I
DS> know--the difference would be what, exactly? :) Regardless, I think this'd
DS> be rather slow, and I don't think it ought to be core.
DS> However...
DS> If you feel the need, it should be possible to let you do this, or at
DS> least a part of it for one or three ops, with a module. I think it might
DS> be better to wait until the plain way's in and then embellish it later.
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
