----- Original Message ----- From: Luke Palmer <[EMAIL PROTECTED]> Date: Thursday, July 22, 2004 2:48 pm Subject: Re: Why do users need FileHandles?
>> JOSEPH RYAN writes: > > > > How would integrating this in the core make it more efficient? Core > > or not, I'd see something like this being implemented with a custom > > pmc. I tend to think of inclusion in the core being more of a > > philosophical decision... > > Yes, it is. Whether or not a PMC is in the core, it should be equally > fast. That is, unless Parrot is allowed intimate knowledge of the > PMC'sinternals. And there are very few (any?) PMCs that possess this > property even now. But why would Parrot need to see the PMC's internals? I was thinking more along the lines of a class just looked just like PerlString, except with different, uh, stuff in the pmc class methods. > Even more philosophical is "what is core?" I get the impression that > Larry is trying to blur the distinction between core and non-core as > much as possible. So making it "go in the core" may just mean > that it's > on the list of recommended modules to install. You're probably right. Every time I think about the idea of "there will be no core modules", a conservative part of me becomes scared out of its mind, and that conservative side wants to riot. But, once I think about it a little more, that riot quickly gets beaten down with thought batons like: "Sure, there won't be any core modules, but most of what Perl5's core will be seamlessly built into the language anyways, and not having other core modules will free everyone from having to continue to use crusty old interfaces like Exporter and File::Find". But, going back to the original topic, something like this kind of I/O abstraction should still be some sort of *module* (core or not), not a core *behaivor*.
