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 

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.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to