From: matz@... (Yukihiro Matsumoto)
Date: 2002-07-03T01:36:31+09:00
Subject: Re: Ruby implementation Q's

Hi,

In message "Re: Ruby implementation Q's"
    on 02/07/02, Justin Johnson <justinj@mobiusent.com> writes:

|> Great.  Can I *steal* your code for the future Ruby? ;-)
|
|How easy is it to convert from C++ to C? ;-)

It depends on how much you "abuse" C++.

|Maybe I can contribute some bytecode work at some time - although it's
|going to take a while.  There are a lot of Ruby implementation issues
|that I have to go through.

I'm waiting.  I'm waiting, eagerly. ;-)

|> Object variables change too often comparing methods, if I don't
|> misunderstand you.
|
|I don't think I explained this very well.  I'm referring to class
|variables.  To fetch a class variable, the runtime may have to
|traverse class hierarchies in the same way that it does for methods. 
|Even though class variables change, their hash is calculation using
|their intern id, so cache behaviour is the same as it is for methods.

Now I understand.  It would reduce the cost of class variable access.
But class variable access can rarely be the bottleneck.

|> Ruby's finalization is kept very primitive intentionally.  It's not
|> for everybody.  Some classes implement optional (or explicit) destroy
|> mechanism, for example:
|
|I understand.  What I'm think about is the ability to remove a
|variable from a class/module.  Because the variable can be removed, it
|would be useful to allow a destroy method to execute before removal,
|so that file closing, system resource freeing etc can be performed.

Hmm, your "removing variable" means something stronger than "removing
object".  I don't think I fully understand you.  All I can say is it
should not be done by method or method like operation.  It requires
special syntax.  This idea is very interesting, but I'm not sure (yet)
whther it is worth merging.  Lisp / Smalltalk / Ruby etc. have had no
problem with the current object model.

							matz.