Programming, Software and Code

Re-Rethinking IO, Again

03 Jun 2009
legacy  —  Parrot  —  IO
Had a good talk with Allison last night about my ongoing IO work, and got a lot of great ideas. It's good to have people in the project that are so great for bouncing ideas off of. We decided a few things:

1. The way I was using "roles" and the does VTABLE was a pretty egregious abuse, and very misleading. It did identify capabilities, but that wasn't the right way to do it.
2. If we're going to support polymorphism, we're going to do it right. Unfortunately, the right way to do it is through methods, which is what I was trying to avoid in the first place.
3. So, for the common case of built-in PMCs and direct subclasses, we can use direct ATTR accesses to do IO quickly. For other types, we default to calling the appropriate method. This does the common case quick, and the fancy-schmance case less quickly.

So, with all this in mind I am going to revert several of the changes I've made to some files, and start redoing things in the "right way". It's never too late to get things right though, and I definitely don't mind the extra work. Here's what this all means:

1. The common case, of builtin PMCs (FileHandle, Pipe, PipeHandle, Socket, StringHandle) will be handled quickly because Parrot's core has an intimate knowledge of the internals of these PMC types. Also, subclassing these types should Just Work, assuming we can abstract things properly so all ATTRs of these types are subclassable (INTVAL, FLOATVAL, STRING * or PMC *). Notice that the C-based PMCs converted with the Pmc2c.pl utility will have difficulty because the base type identifier will not match that of the builtin PMC types.
   
2. The uncommon case, of using any arbitrary PMC type for IO, will be supported but less quickly. We will call named methods to implement various behaviors ("read" method to read, "open" method to open, etc).
   
3. The user-visible interface won't be changing through any of these refactors, so we won't need a deprecation cycle. It's an in-place optimization.

So that's the changes in a nutshell, and I'm hoping that the end result is good and fast for most cases. I'm hoping to power out some changes this week before some of my other projects take over most of my free time. I am still planning to have these IO refactors land before the next release, so that I can get working hard on AIO in July.

This entry was originally posted on Blogger and was automatically converted. There may be some broken links and other errors due to the conversion. Please let me know about any serious problems.