<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY><FONT face=Arial color=#0000ff size=2></FONT><BR><BR>
<P><FONT size=2>-----Original Message-----<BR>From: GeneCox [<A
href="mailto:putizi@21cn.com">mailto:putizi@21cn.com</A>]<BR>Sent: Monday, April
02, 2001 9:57 AM<BR>To: squeak@cs.uiuc.edu<BR>Subject: Object, or Attribut, or
something else...<BR><BR><BR>Hi, Smalltalkers<BR><BR>Almost everything in
SmallTalk is interesting, but not its classes tree;-)<BR><BR>To my opinion, some
kind of clarifying still needs to be make. Since I use English as a<BR>foreign
language I just try my best to explain as follows:<BR><BR>Being a Chinese, and
with a good knowledge of Eastern Philosiphy, I don't see anything<BR>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.<BR><BR>Different levels of classifying or grouping have
nothing to do with heirarchy at all. And<BR>keep this clear will help SmallTalk
a lot as a pure class-based language.<BR>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.<BR><BR>For instance, say I am a man, middle aged, tall,
used to be a proffessor and now work for<BR>some ABCD company as Mananger of
Marketing Department or something, then I could be grouped into these
classes:<BR>
Man<BR>
MidAged<BR> Tall
people<BR> People who have changed
job<BR> Company employees<BR>which
class should I belonging to? I simply be someone who posess, or be composition
of all these attributes.<BR><BR>The root of the Smalltalk Classes Tree should be
Atrribute, not Object.</FONT></P>
<P><FONT size=2><FONT face=Arial color=#0000ff>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.</FONT></FONT></P>
<P><FONT size=2><FONT face=Arial color=#0000ff>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
... </FONT></FONT></P><FONT size=2><FONT face=Arial
color=#0000ff></FONT><FONT face=Arial color=#0000ff></FONT><FONT face=Arial
color=#0000ff></FONT><FONT face=Arial color=#0000ff></FONT>
<P><BR></FONT><FONT size=2><BR>Say, I learned math in college, Mr Octave be the
Proffessor who taught me, and I learned some<BR>music from Miss Doremi, adding
to a lot of other things from other people.<BR>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.<BR>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.<BR><BR>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.<BR>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!<BR><BR>The knowledge part
is less noticed, and thrown into some class/instance or class instance variables
in a term of "data". Think it over.<BR>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:<BR><BR>Bonny keep: Number new as: #age. "this will get things run.(maybe,
#keep:for: --you know my English is not good ENOUGH)"<BR>Bonny age: 10.
"the system will generate set/get method automatically"<BR>Bonny prop: #age
ifTrue:[ Bonny age printOn: blackboard ].<BR>Bonny age: Bonny age + 1.<BR>Bonny
forget: #age. "forgetting something like a real Bonny.
All relative methods frozen."<BR>Bonny
age.<BR> => some inform for
Exception occur.<BR><BR>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):<BR><BR>initialize<BR>"I will prepare my memory for everything, and
the set/get pair of methods will be
ready."<BR><BR> self
keep: Number newInstance as: #age; "the programmer
want this be checked later."<BR>
keep: nil as: #hobby; "not
checked when using #hobby: something message
later."<BR>
keep: Fruit newInstance as:
#favour; "not
Vegetables..."<BR>
keep: JavaBean UglyFace as:
#afraid. "...Java?! Maybe a joke."<BR><BR>and system will
generate some methods include "querying" ones as #component and
#knowledge:<BR> Bonny component.
"componet attributes, all more easy to understand,
capabilities."<BR>
=> #(#knowledge ->
#(<BR>
#age ->
#aNumber<BR>
#hobby ->
#nil<BR>
#favour ->
#aFruit<BR>
#afraidOf -> #'a JavaBean
UglyFace'<BR>
#and ->
#someOthers)<BR>
#behavior ->
#(<BR>
#age
#age:<BR>
#hobby
#hobby:<BR>
#favour
#favour<BR>
#afraid
#afraid:<BR>
#sleep #run #eat
#sing<BR>
#etc
))<BR> Bonny
knowledge.<BR>
=> #(#age #hobby #favour
#afraid) <BR>
"not knowledge-gaining/showing
actions, though looks alike"<BR></FONT></P>
<P><FONT size=2><FONT face=Arial color=#0000ff>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 ).</FONT></FONT></P>
<P><FONT size=2><FONT face=Arial color=#0000ff>Also we implemented on top of
Smalltalk a Fuzzy-Prolog which focusses more on modelling rules than class -
relationships.</FONT></FONT></P><FONT size=2><FONT face=Arial
color=#0000ff></FONT>
<P><BR>If you like change, then include #behavior in place of existing similar
one to report all its unique behaviors as to its "working class".<BR><BR>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.<BR>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.<BR>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.<BR><BR>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.<BR><BR>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.<BR>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.<BR><BR>Tea or
coffee, that's not the question.<BR>Only important thing is that some Smalltalk
water, will, make it.<BR>Thank all of those who invented Smalltalk and have ever
contributed to it! Otherwise many people would have lived in darkness
:-)<BR><BR><BR>Good
luck!<BR><BR>
GeneCox<BR>
genecox@21cn.com<BR><BR>(This letter was originally for discussion on another
topic.)<BR>>On Thursday 29 March 2001 14:37, Karl Wilson wrote:<BR>>>
why doesn't it say something like:<BR>>><BR>>> ProtoObject class
subclass #Object class<BR>>><BR>>>
instanceVariableNames: ''<BR>><BR>>When you do "ProtoObject subclass:
#Object ..." this method takes care<BR>>of all these little details
automatically.<BR>><BR>>> and why can't you spawn a class side
heirarchy?<BR>>><BR>>> Behavior<BR>>>
ClassDescription<BR>>>
Class<BR>>>
ProtoObject class<BR>>>
Object class<BR>><BR>>Ooops - I
had said you would reach "Behavior class" but that was wrong.<BR>>Since the
system created all these metaclasses behind your back and<BR>>doesn't even
bother to give them proper names, showing them like this<BR>>would probably
cause more confusion. It is easy to patch the tools to<BR>>do this, but I
don't think it is a good idea.<BR>><BR>>> I am sure this will all make
sense after awhile. Thanks again.<BR>><BR>>Others have given a lot of
great pointers to more information about<BR>>this than most people want to
know. I prefer the alternative adopted by<BR>>the Self dialect of Smalltalk -
simply design this complication out of<BR>>the language! </FONT><A
target=_blank href="http://www.sun.com/research/self/"><FONT
size=2>http://www.sun.com/research/self/</FONT></A><BR><FONT
size=2>><BR>>-- Jecel<BR><BR><FONT face=Arial color=#0000ff>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.</FONT></FONT></P>
<P><FONT face=Arial color=#0000ff size=2>Frank</FONT></P>
<P><FONT size=2><FONT face=Arial
color=#0000ff></FONT> </P></FONT></BODY></HTML>