Rocco Caputo wrote: > Re: Writing the subsystems together. > > I think you misunderstand the other message's intent. The main loop, > the interpreter, and I/O, are three separate subsystems. I think > everyone agrees with you that they should be interchangeable, but > their public interfaces are sufficiently intertwined that they should > be designed, at least at their borders, as a complete system. > > > >In the other way around, what matters to the design of the file i/o > >subsystem is exactly the same thing: whether it will or won't be using > >blocking syscalls. I believe after the decision of whether we will or not > >allow blocking (I think most of us go for no blocking..., but see my remark > >about portability above), the file i/o subsystem MUST be designed in a > >complete modular fashion. > > I think this is where vtables come in. If perl itself were to use > them, each subsystem could plug itself in at link time. It may even > be possible to defer subsystem plug-ins until their language-level > interfaces are used. > > I've also experimented with plug-in subsystems at the Perl module > level in the poe2 project. Its resource management scheme might be > a useful springboard for pluggable Perl subsystems. poe2's resource > manager is at <http://poe.perl.org/poe2/POE.pm>. The rest of the > project is in the same directory, including current tarball of the > entire tree. > > > >That's actually something I'd like to say about this ``subsystem''-based > >design of perl6. For it to be successful, it's imperative that all the > >modules > >don't know about each other, so that it's possible to replace a subsystem > >completely for another that supplies the same interfaces, as it should be > >possible to use a subsystem in another program, for example, it should > >be possible to use the async i/o subsystem in a C application (through the > >low-level interface), linking it directly to the application, without the > >necessity to link the whole perl runtime to the application. > > > >At least, that's what I think. What's your opinion? > > If you mean that subsystems need to understand each others' public > interfaces and nothing more, then I agree. Otherwise, how would one > subsystem call another if it didn't know what to call? > > Subsystems should stand alone wherever possible, but I think isolating > them from Perl data types would make little sense. Why create a great > data manipulation library only to rewrite it in every subsystem? > > -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net > > > I'm sorry I didn't express myself OK..., but we're in violent agreement. Please read my previous post to the perl6-internals mail-list, entitled ``Modular subsystem design (was Re: Speaking of signals...)'' Your ``pluggable'' idea is just what I was looking for. To me, that's what perl6 needs to be. Branden
