-----Original Message-----
From: GeneCox [mailto:putizi at 21cn.com]
Sent: Monday, April 02, 2001 9:57 AM
To: squeak at cs.uiuc.edu
Subject: Object, or Attribut, or something else...


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.

the st class tree should be viewed from the smalltalk-language definition -
Object is a root for all Classes whose instances can be regarded as
Objects - i.e have an identity - ProtoObject allows defines a minimum
protocoll for objects.

the above counterexample would be modelled in st using a Role
Design-Pattern - belonging to a class can be also change over time - so a
Person has a Role ...



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"


The above idea focuses on the Knowledge based approach - such systems can be
implemented on top of Smalltalk - there was GOLD a frame-based language on
top of Actor ( a Smalltalk like OO - language ).

Also we implemented on top of Smalltalk a Fuzzy-Prolog which focusses more
on modelling rules than class - relationships.


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

Self differs of course - but also it can be implemented on top of
Smalltalk - Visual Smalltalk's PARTS allows for defininig methods (
scripts ) on instances.

Frank



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010402/961107bc/attachment.htm