[newbie] how does Object implement new?

GeneCox putizi at 21cn.com
Sat Mar 31 03:36:35 UTC 2001


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

To my opinion, some kind of clarifying still is in need. 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 language). Sorry, I haven't read a lot, before I say this, of documents here and there on the net. I'm not 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 chaos came out of mistaking objects but not their attributes to be the main role or 
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, then I am 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 all these attributes.
The root of the Smalltalk Classes Tree should be Atrribute, not Object.
And the puzzle of multi- or singular- heirarchy will also be solved.

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 Heirarchy occurses. But one will not be son of their teachers simply because he has learned 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 to treat anObject as be 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 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!

For now, 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: 10 as: #age. (or, #keep:for: --you know my English is not good ENOUGH)
Bonny pop: #age ifTrue:[ Bonny awarded. Bonny age printOn: blackboard ].
Bonny age: Bonny age + 1.
Bonny forget: #age.

The system will manage those hiden things better than programmers, for instance, we 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"
	self 	keep: Number newInstance as: #age;	"the programmer want this be checked"
	      	keep: nil as: #hobby;	"not checked"
			keep: Fruit newInstance as: #favour;	"not Vegetables..."
			keep: JavaBean UglyFace as: #afraid.	"...Java?!"

and system will generate some methods include "query" ones as #component and #knowledge:
	Bonny component.
		=> #(#knowledge -> #(#aNumber #nil #aFruit #'a JavaBean UglyFace' #andOthers)
			#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 to report all its unique behaviors as to its "working group". 

At least the OO manner will be enforced, and Smalltalk objects made up of atrributes 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!).
A additional #canActAs: aPresident method would make Bonny act like a President whenever the Course would comfirm that. Yet this is not multi-heirarchy, 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 itself into some 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 some good code to make advantege of Java and JavaBeans, you may want to make a try.
 
Tea or coffee, that's not the question. 
Only important thing is that some Smalltalk water, will, make it.

Thanks for all of those who invented Smalltalk and have ever contributed to it! Otherwise many people would live in darkness.


at 2001-03-29 17:40:00 you wrote£º
>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


Good luck!

            GeneCox
            genecox at 21cn.com





More information about the Squeak-dev mailing list