Object, or Attribut, or something else...

GeneCox putizi at 21cn.com
Mon Apr 2 15:59:03 UTC 2001


Hans-Martin Mosner£¬
	
	Thank you for your patient. I learn a lot from your words. I want to make something clearer, for I think it be valuable.

at 2001-04-02 10:23:00 you wrote£º

>I think that there is a common misconception that Smalltalk's class tree is
>somehow carrying the 'meaning' or 'intention' of Smalltalk programs. It isn't.
>Class inheritance is just a mechanism for code sharing, nothing spectacular.
Yes... but the design could be influenced much by the way you modeling the world and 
I was trying to say that take classes as containers holding grouped attribute-blocks might
result in better code sharing mechanism and tidier building of class library.

>In the current Smalltalks, the relation of objects to their message catalogs
>(via their class) is rather fixed, which has the undesirable effect that your
>examples of accumulating and refining knowlege about some real-world entity
>can not be directly modeled...
Though it still would be not too difficult to achieve that even in current system. Performance not concerns, adding a variable #memory and some simple methods like #keep:as/for: to the current root Object( for these attributes will be in common among all) and something more, then a few trikes using blocks might at last make it, but this is *not* what I was seeking for. An attribute-centered ( or some other terms in better English ) Smalltalk system can be very different, and make these kind of things very easy to implement, may we just treat it as  side effects.

>.......
>Things like age, current profession etc. They have nothing to do with class
>based inheritance at all. It's very easy to create a kind of 'attribute-holding'
>object which can dynamically gain and lose attributes.
What is that in object besides its attributes, but still will hold them( those attributes)? With the term attributes I mean information exchanging and action taking "capabilities", or knowledge and behavior accordingly. (Or variables and methods, if it will make it clearer.)

Let me put it like this: when looking at codes shared among objects, I see attributes, shared, which can be well grouped as classes while some other people might see inheritance, which, I believe to have made things complicated. And the main difference is, object can be build of attribute blocks across classes(of attributes) with ease if we would like to forget something we put on them as inheritance. 
I hope it is worth discussing.

>Prototype-based languages, such as Self which Jecel mentioned, have taken that
>approach to implement full systems. From a practical programming perspective,
>I prefer the Smalltalk way of making classes explicit, because I feel that
>code is much more tangible in such a system. 
I agree. Yet classes as attributes grouped together will not sacrifice anything of value in the current system. It will only make the system tidier, simpler, and clearer, surpose we are not to make use of any side effects.

	Thank you again, and
Good luck!

            GeneCox
            genecox at 21cn.com





More information about the Squeak-dev mailing list