The second attempt to multilingualize Squeak, based on 3.2 release, pre-alpha version

Andreas Raab andreas.raab at gmx.de
Fri Mar 21 20:49:28 UTC 2003


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
> 



More information about the Squeak-dev mailing list