At 04:13 PM 10/8/00 -0600, Nathan Torkington wrote:
>I've heard people asking for RFCs to continue after the brainstorming.
>What do we want to do that we need RFCs for? Design? Implementation?
>Working out the fine details of behaviour?
What I'd like to see is the internals design and implementation use RFCs as
the specifications and documentation for the different pieces of the guts.
I'm not sure the free-for-all way we handled things to start is appropriate
(I'm rather sure it's *not*), but that's OK, since the requirements are
different.
Much as folks might dislike it, I think some sort of prefilter is in order
for RFCs if we continue that way. (We'll be doing *something* of the sort
on the internals side) RFCs should have at least some solidity before they
hit the standards track. Feasable would be nice, but if someone wants to
present an alternative to the current implementation of something (vtables,
variables, interpreter structure) that's fine--we may need a Plan B at some
point. Or Plan C, since I suppose we're working on Plan B now.
The separate sub-lists are definitely a useful tool in some circumstances,
and I'd like to see those used as well. The internals encompasses a lot of
area, and having separate lists should make life an awful lot easier.
(Whether this ultimately proves to be true is a separate issue) The folks
designing the bytecode don't, for example, need to interact a whole lot
with the folks designing the garbage collection code.
All this might just be an internals-only issue, and if that's the case then
I'm fine with that. If it's not, though, it seems to make sense to
coordinate things project-wide.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
