Hmm, thanks for that clarification.

Maybe bug is a bad word. Let me start over - it might be nice understand
to "what kinds of changes cause what kinds of problems in which of the
dangerous classes?". For example, one might think that redefining the
superclass of String should be illegal (as it is prevented by
tooDangerous). As it happens, it seems to work. 

For example, is inserting a superclass always safe (assuming it doesn't
affect shape - without instance variables, of the same class type)? what
invariants might be at stake?

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> Daniel,
> 
> There are Many Very Good Reasons (tm) not to allow people to even
> accidentally recompile some of the critical classes. This is mostly because
> the class definition is evaluated as an expression and that means that
> anything going into that path should absolutely be guarded. In this sense,
> no it is NOT a bug of any kind, it is a deliberate fence. However, if you
> look at the sender of #tooDangerousClasses you will notice that this method
> accepts an parameter (unsafe) which allows you to do anything you want, even
> breaking your system in the most horrible ways possible, if you absolutely
> want to. Since this method is the ultimate entry point into the entire
> machinery you can absolutely invoke it - you simply have to provide all the
> parameters explicitly. So that (for example)
> 
> ClassBuilder new
> 	name: #String
> 	inEnvironment: String environment
> 	subclassOf: MyStringBaseClass
> 	type: String typeOfClass
> 	instanceVariableNames: String instanceVariablesString
> 	classVariableNames: String classVariablesString
> 	poolDictionaries: String sharedPoolsString
> 	category: (SystemOrganization categoryOfElement: #String) asString
> 	unsafe: true
> 
> will absolutely work. Again, changing any of the classes that are listed in
> this method should never be done lightly and therefore, no it's absolutely
> no bug.
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: squeak-dev-bounces at lists.squeakfoundation.org 
> > [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> > Behalf Of Daniel Vainsencher
> > Sent: Friday, March 21, 2003 8:33 PM
> > To: The general-purpose Squeak developers list
> > Subject: Re: The second attempt to multilingualize Squeak, 
> > based on 3.2 release, pre-alpha version
> > 
> > 
> > Hi Yoshiki.
> > 
> > I'm reading your paper on the design and implementation of these
> > changes. It is very interesting. If I understand correctly, the only
> > reason that a system tracer is needed, is that String's superclass
> > cannot be changed by recompilation. You explain that this is caused by
> > the VM holding a pointer to the String class.
> > 
> > I was wondering if we shouldn't consider that to be a kernel bug. This
> > would allow the work in question to be released as a simple loadable
> > change set or two, without the need for cloning.
> > 
> > >From a look at the error raised when I try to run change the 
> > superclass,
> > it appears that String is hard coded as one of the classes 
> > known by the
> > VM, and therefore are dangerous. Since your work doesn't 
> > actually change
> > the class structure, it seems this should not be forbidden. In fact,
> > removing String from the tooDangerous method actually allows me to do
> > the required change without a problem (as far as I can tell). 
> > 
> > I'm not arguing that removing String from tooDangerous is 
> > itself a good
> > idea permanently, but it's a work-around for what appears like a
> > too-strict limit in ClassBuilder.
> > 
> > Daniel
> > 
> > Yoshiki.Ohshima at acm.org wrote:
> > >   Hello,
> > > 
> > >   I just updated a couple of Swiki page and uploaded the 
> > multilingual
> > > Squeak code.  This is nothing more than pre-alpha (or 
> > pre-pre-alpha),
> > > which I barely hope that it conveys the general design idea.
> > > 
> > >   For those who wants to try it, visit 
> > > 
> > > http://minnow.cc.gatech.edu/squeak/919
> > > 
> > > and follow the instructions.
> > > 
> > >   I really like to improve the system and hope one day we 
> > can make the
> > > unified version of Squeak which works as a vehicle for the 
> > world-wide
> > > communication and idea-sharing.  So, feel free to send comment,
> > > critic, and of course, code.
> > > 
> > >   Hopefully, I can set up a update stream for this 
> > particular version
> > > of Squeak to track the changes we are going to make.
> > > 
> > >   Enjoy and Thank you!
> > > 
> > > -- Yoshiki
> >