I have what I consider a better reason not to want to see the suggested 
idea researched in the public core Squeak code -- I use Squeak because 
it's free (important to me) and Smalltalk (more important to me) -- NOT 
some other language, like Self.  From postings I've seen, both for this 
thread and (much) earlier ones, I gather that any time I want to program 
with Self, I can download an image and start hitting keys.  But I don't 
want to program in Self, I want to program in Smalltalk, and Squeak fits 
that model closely enough for my purposes.

Conversely, I see nothing wrong with *forking* a copy of the public core 
Squeak code, making the changes suggested for the research, and making 
it publically available as something else, such as "Eek" or "Squawk", or 
whatever, and setting up "Eek" web sites, Eek discussion lists, and 
encouraging Eek porting efforts.  I might even subscribe myself, and 
after a while might even think it worth my time to drop Squeak in favor 
of Eek.  I just think that despite the intent of Alan Kay, Dan Ingalls 
and company to do research with Squeak as a starting point, in both 
"pink" and "blue" planes of  endeavor, Squeak-as-a-Smalltalk has too 
much momentum to change into Squeak-as-a-something-else -- unless a 
relatively clean break is made to create something like 
Eek-as-something-other-than-Smalltalk.

And of course, what anyone does in the privacy of their own personal 
Squeak (or Eek) image is their own business, and I have no objections to 
research conducted therein at all.

Of course, I suppose one could argue that we should fork off a Squeak 
image to become Eek, a Smalltalk, while Squeak moves on to become 
something else...

Nah!  :-)

Stephen Pair wrote:

> Nathanael Schärli wrote:
>
>> Hi Martin,
>>
>>  
>>
>>> But you loose something, namely encapsulation. Every object outside
>>> morph can screw the state of this morph, without doing 'more' to it, 
>>> meaning this morph will be put in an unvalid state.
>>>   
>>
>>
>> I think that the argument about "loosing encapsulation" is complete
>> bogus because it has no relevance in practice. In fact, encapsulation
>> means:
>>
>
> [lot's of good stuff snipped]
>
> I totally agree with Nathanael's comments...looking at instance 
> varaibles as if they were somehow untouchable or private is the wrong 
> way of looking at it.  It's very similar to the argument in favor of 
> having public/protected/private methods.  First, you can always get an 
> an object's inst vars using #instVarAt:(put:)...so any argument that 
> there is encapsulation is wrong.  There isn't.  There's just some 
> notion that gives the user of the class some idea of what's safe and 
> what's not safe to do.  I tend to view the notion of 
> public/protected/private methods as a feeble attempt at classifying 
> methods based on how likely it is that their interface will change 
> over time (private being the most likely, public being the least).  
> Similarly, an instance variable without direct getters/setters is 
> simply a comment saying "don't directly get or set this inst var, or 
> if you do, then be prepared to accept the consequences when I release 
> my next version."
> Encapsulation is really only achieved by responsible usage of the 
> interfaces exposed by a class.
> So, to say that you're losing encapsulation is simply not accurate.  
> You might be loosing some interface notational capability, but you are 
> not losing encapsulation because you cannot lose what you never had in 
> the first place.
>
> - Stephen
>
>
>
>

-- 
 ..	Donald Major		"Tech Support..your Windows machine doesn't
dtm	SAS Institute Inc.	 work?  Have you tried installing a Macintosh?"
	Cary, NC 27513			- me          SAS - "The Power to Know"
	AKA "Ol' Baby Lee"