Hi, Smalltalkers

Almost everything in SmallTalk is interesting, but not its classes tree;-)

To my opinion, some kind of clarifying still needs to be make. Since I use English as a
foreign language I just try my best to explain as follows:

Being a Chinese, and with a good knowledge of Eastern Philosiphy, I don't see anything
of a real heirarchy in Smalltalk( or any OO children languages). Sorry, I haven't read a lot, before I say this, of documents here and there on the net. I cannot afford to do that in China.

Different levels of classifying or grouping have nothing to do with heirarchy at all. And
keep this clear will help SmallTalk a lot as a pure class-based language.
The puzzle came out of some kind of mistaking objects but not their attributes to be the main target when the class-tree was invented.

For instance, say I am a man, middle aged, tall, used to be a proffessor and now work for 
some ABCD company as Mananger of Marketing Department or something, then I could be grouped into these classes:
	Man
	MidAged
	Tall people
	People who have changed job
	Company employees
which class should I belonging to? I simply be someone who posess, or be composition of all these attributes.

The root of the Smalltalk Classes Tree should be Atrribute, not Object.

Say, I learned math in college, Mr Octave be the Proffessor who taught me, and I learned some
music from Miss Doremi, adding to a lot of other things from other people.
Here somebody will see something of inheriting occur. But one will not be son of their teachers simply because he has learned("inherited") something from them and objects in a Smalltalk class tree never have such teacher-student relationship. 
It is far more clear to look at things this way, that anObject is made up of someAttributes( relations with others), and atrributes can be grouped if they are common ones shared among some objects. (When talking about a piece of attribute particularly, it is correct to say anObject belongs to some group, but only in that aspect). And these groups can still be grouped, to an imaginaryAtrributeRoot, which represents atrributes common among all objects.

Some thing else will emerge from this kind of clarifying. For Atrribute should at once be divided into(fall into) two groups as knowledge and behavior. And the knowledge part of anObject's atrribute shows itself up when it gives some information to other objects or gains some from others, while the behavior part can be "seen" when the object does something to cause other objects or itself to change. Giving/gaining information, of course, is a kind of behavior.
All what a SmallTalk object needs is just, and at least, these two part of attributes. Because they are not a real phisicaly object at all!

The knowledge part is less noticed, and thrown into some class/instance or class instance variables in a term of "data". Think it over.
If it has been correct to emphases the behavior part of anObject's attributes in that all its knowledge will be invisible unless it does something(perhaps influences others), then why not take a step forward to throw away those C/I or C.I. variables? Just let object learn something, tell something, and manage its knowledge or memory. Take a look at these:

Bonny keep: Number new as: #age. "this will get things run.(maybe, #keep:for: --you know my English is not good ENOUGH)"
Bonny age: 10.	"the system will generate set/get method automatically"
Bonny prop: #age ifTrue:[ Bonny age printOn: blackboard ].
Bonny age: Bonny age + 1.
Bonny forget: #age.	"forgetting something like a real Bonny. All relative methods frozen."
Bonny age.
	=> some inform for Exception occur.

The system will manage those hiden things better than programmers, for instance, people only need to care about what the target object should know and what it will do, and decide accordinly which group should be the most efficient to reside it in, and some kind of type check can be available at once though it's free to use or not use( I use newInstance instead of new to emphasize the group-individual relationship of atrribute classifying):

initialize
"I will prepare my memory for everything, and the set/get pair of methods will be ready."

	self 	keep: Number newInstance as: #age;	"the programmer want this be checked later."
	      	keep: nil as: #hobby;	"not checked when using #hobby: something message later."
			keep: Fruit newInstance as: #favour;	"not Vegetables..."
			keep: JavaBean UglyFace as: #afraid.	"...Java?! Maybe a joke."

and system will generate some methods include "querying" ones as #component and #knowledge:
	Bonny component. "componet attributes, all more easy to understand, capabilities."
		=> #(#knowledge -> #(
				#age -> #aNumber 
				#hobby -> #nil 
				#favour -> #aFruit 
				#afraidOf -> #'a JavaBean UglyFace' 
				#and -> #someOthers)
			#behavior -> #(
				#age #age: 
				#hobby #hobby: 
				#favour #favour 
				#afraid #afraid: 
				#sleep #run #eat #sing 
				#etc ))
	Bonny knowledge.
		=> #(#age #hobby #favour #afraid)	
		"not knowledge-gaining/showing actions, though looks alike"

If you like change, then include #behavior in place of existing similar one to report all its unique behaviors as to its "working class". 

At least the OO manner will be enforced, and Smalltalk objects made up of atrributes( capability in knowledge and behavior) will be able to change themselves all the time, just like their model real objects( for you can always ask it to keep: something as/for: #aSelector, then make use of that!). Because changes only occur within the knowledge part, it is not the same as some dynamatic object.
For the amount of attributes shared among objects will be much less than the number of different "object classes" what we have now, it will make the liborary much smaller. For many of the classes existing are in fact instances of the attribute-composition.
With time much more things could change if this Attribute centered tech would be accept by Smalltalkers. No more discussion on those composition mannered instance creation is needed here.

An additional #canActAs: aPresident method or something would make Bonny act like a President whenever the Court would comfirm that. Yet this is not multi-heirarchy or multi-inherits, but multi-grouping at different level for different situations or aspects and Bonny's knowledge and behavior will change. 

Also, this will give the system a chance to mask the Smalltalk programms, one may call it some kind of a Language Wraper, when it's in need. 
For example, Smalltalkers will easily use any libs available no matter which language they are originally stemed from as long as Squeak will mask the codes to run on their Virtual Machines, for instance, say Java VMs. When you browse the IBM homepage searching for NetRexx and then find that this <500k sized little thing generates(calls JDK to do the job) some good code to make advantege of Java and JavaBeans, you may want to have a try.
 
Tea or coffee, that's not the question. 
Only important thing is that some Smalltalk water, will, make it.
Thank all of those who invented Smalltalk and have ever contributed to it! Otherwise many people would have lived in darkness :-)


Good luck!

            GeneCox
            genecox at 21cn.com

(This letter was originally for discussion on another topic.)
>On Thursday 29 March 2001 14:37, Karl Wilson wrote:
>> why doesn't it say something like:
>>
>> ProtoObject class subclass #Object class
>>
>> 	instanceVariableNames: ''
>
>When you do "ProtoObject subclass: #Object ..." this method takes care 
>of all these little details automatically.
>
>> and why can't you spawn a class side heirarchy?
>>
>> Behavior
>> 	ClassDescription
>> 		Class
>> 			ProtoObject class
>> 				Object class
>
>Ooops - I had said you would reach "Behavior class" but that was wrong. 
>Since the system created all these metaclasses behind your back and 
>doesn't even bother to give them proper names, showing them like this 
>would probably cause more confusion. It is easy to patch the tools to 
>do this, but I don't think it is a good idea.
>
>> I am sure this will all make sense after awhile. Thanks again.
>
>Others have given a lot of great pointers to more information about 
>this than most people want to know. I prefer the alternative adopted by 
>the Self dialect of Smalltalk - simply design this complication out of 
>the language! http://www.sun.com/research/self/
>
>-- Jecel