Douglas, I think you get the basic idea, and your own refinement of having a common nil-like parent is kind of interesting. Though the behavior shared by these "not yet specified" or nil-like objects is curiously hard to articulate. I mean, what is the essence of vagueness?
If you can come up with something, implement it, use it, and extract a lesson or two, it might be an interesting OOPSLA paper.
(In my opinion!)
--Randy
Remember that discussion on the usefulness of nil and the default initialization of slots? I was reading the Self 4.0 ProgrammerŽs Reference Manual this weekend and thought a little bit more about the purpose of nil. If I got the idea, nil should not be used as a default initializer, instead a specific object should be created to mean "no object here" in the particular context. Well, perhaps (I don't remember if anyone said this) nil could be used as a prototype of this kind of object, or a traits, so that the common behavior of all "null" objects would be concentrated on it. Is it already so? I understand that nil is one object, and as such it has one type. So if one uses it to represent "no object" in places where different types are being represented, then one is losing type information. If we create other objects to play this role, so that nil is their parent, or so that they are cloned from nil, perhaps we can keep the commonality of the nil "family" and also keep different nil's for different "types". Did I get the idea, folks? Do I make a point?
Douglas
GET $10 OFF ANY ORDER @ healthshop.com! No min. purchase req. Save on vitamins & supplements. Use coupon code: EGROUPS at checkout http://clickhere.egroups.com/click/432
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
Randall (or Mr. Smith, may I be more informal?), I have been making small programs in C++ which used the Standard Library collections, in which I represented both "undefined" and "non-existent" contained objects with NULL. I have also read some article about dropping the NULL and using a NullObject class in place of it, but it seemed cumbersome to have an object instantiated just for that. Objects seemed just too expensive to "throw away" like that. Now I am changing my mind about the efficiency concerns vs. ease of programming and clearness of representation. It's because in Self one thinks in terms of objects only and not in terms of classes or data. So one can only worry about an object if it exists. nil itself is an object and can have slots.But the problem of confusing types continues to exist because nil is one object, likely to be used in many different places. Perhaps, if a specialized nil object could have two parents, one would be the common parent of the objects whose absence that nil represents, the other could be the nil prototype. In fact, it seems that nothing is due to belong to all nil's but the fact that they all represent absence of undefinedness. See comments below. Regards, Douglas
Randall.Smith@Eng.Sun.COM wrote:
Douglas, I think you get the basic idea, and your own refinement of having a common nil-like parent is kind of interesting. Though the behavior shared by these "not yet specified" or nil-like objects is curiously hard to articulate. I mean, what is the essence of vagueness?
I have learned at school that one cannot sum oranges and bananas. But if you have a collection of oranges and another of bananas, and some of them are not in the collection, one can represent them with nil, meaning the nil-fruit. What would this nil-fruit be like, to be regarded as a banana and also as an orange? No way. I don't see commonality in different nil's. If we have a nil-banana and a nil-orange and each represents the absence of the corresponding fruit, then in a collection of bananas we could treat the nil-banana as a banana (either an undefined or an absent banana) and in a mixed collection we could know if the place occupied by one of these nil-fruits is a place for bananas or for oranges.
If you can come up with something, implement it, use it, and extract a lesson or two, it might be an interesting OOPSLA paper.
(In my opinion!)
This could travel far away through a highly-mathematical/ -logical path. I don't feel confident to try it. It is really difficult to think about commonality of objects that represent the absence of other objects. I am not sure about this essence of vagueness. Perhaps these objects could be a place to do error handling, or to provide behavior only available when something is absent, I don't know exactly. I don't think nil-like objects would have some common state (in the form of data slots), unless for an implementation detail. Anyway, I just felt that the traits and common behavior for nil was missing in Self.
--RandyRemember that discussion on the usefulness of nil and the default initialization of slots? I was reading the Self 4.0 Programmer´s Reference Manual this weekend and thought a little bit more about the purpose of nil. If I got the idea, nil should not be used as a default initializer, instead a specific object should be created to mean "no object here" in the particular context. Well, perhaps (I don't remember if anyone said this) nil could be used as a prototype of this kind of object, or a traits, so that the common behavior of all "null" objects would be concentrated on it. Is it already so? I understand that nil is one object, and as such it has one type. So if one uses it to represent "no object" in places where different types are being represented, then one is losing type information. If we create other objects to play this role, so that nil is their parent, or so that they are cloned from nil, perhaps we can keep the commonality of the nil "family" and also keep different nil's for different "types". Did I get the idea, folks? Do I make a point?
Douglas
GET $10 OFF ANY ORDER @ healthshop.com! No min. purchase req. Save on vitamins & supplements. Use coupon code: EGROUPS at checkout http://clickhere.egroups.com/click/432
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
FreeShop is the #1 place for free and trial offers and great deals! Try something new and find out how you could win two round-trip tickets anywhere in the U.S.! http://clickhere.egroups.com/click/368
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
On Wed, 07 Jul 1999 15:53:16 -0300 Douglas Atique wrote:
I have been making small programs in C++ which used the Standard Library collections, in which I represented both "undefined" and "non-existent" contained objects with NULL. I have also read some article about dropping the NULL and using a NullObject class in place of it, but it seemed cumbersome to have an object instantiated just for that. Objects seemed just too expensive to "throw away" like that. Now I am changing my mind about the efficiency concerns vs. ease of programming and clearness of representation. It's because in Self one thinks in terms of objects only and not in terms of classes or data. [...]
This is a very important point. It is too costly to make a new class to "reify" some concept in an applications, but we can make as many new (prototype) objects we want with no worries. For example, if we need to return three values from a method we can simply create a new kind of object with three data slots, stuff it with the values and then return this object as the result.
A lot of my Self programs show some bad habits that I picked up with other languages. I'll give an example from the Self UI instead, however, to save myself some well deserved embarrassment ;-)
If you look at a simple morph, you will see two slots called 'hResizing' and 'vResizing'. They can have as values the integers 0 (meaning rigid), 1 (meaning flexible) or 2 (meaning shrinkWrap). This is all very nice, but we have to have methods in traits morph like:
isFlexibleHorizontally = (1 = hResizing)
and
layoutDescription = ( | r | r: 'h: '. isRigidHorizontally ifTrue: [ r: r, 'rigid']. isFlexibleHorizontally ifTrue: [ r: r, 'flexible']. isShrinkWrapHorizontally ifTrue: [ r: r, 'shrinkWrap'].
r: r, ', v: '. isRigidVertically ifTrue: [ r: r, 'rigid']. isFlexibleVertically ifTrue: [ r: r, 'flexible']. isShrinkWrapVertically ifTrue: [ r: r, 'shrinkWrap'].
r)
Now imagine that we had three little objects called 'rigid', 'flexible' and 'shrinkWrap', where some of the slots in 'flexible' could be:
flexible = ( | isRigid = false. isFlexible = true. isShrinkWrap = false. name = 'flexible'. | )
We could replace the expression 'isFlexibleHorizontally' with 'hResizing isFlexible' (though some people would object that I am "breaking the morph's encapsulation", here) and we would have a method:
layoutDescription = ( 'h: ', hResizing name, ', v: ', vResizing name )
which looks much nicer to me. By adding a few more methods to our three new helper objects, there are several more methods in 'traits morph' and 'spaceAllocator' that could be made slightly simpler as well. Is it worth doing this? Not in Smalltalk, C++ or Java. But I would vote for this programming style when the language is Self.
-- Jecel
self-interest@lists.selflanguage.org
-
Douglas Atique -
Jecel Assumpcao Jr -
Randall.Smith＠Eng.Sun.COM