Re: Sets with nil
Locked
 
|
I appreciate that being able to add nil to a Set is useful.
All the discussion so far seems to be based upon how to implement such a change efficiently and safely. I would like to point out that there is a negative to allowing nil to be added to a set and as it happens it applies to every instance of Set I have ever used (at least directly). A common bug in programs is to have an object set to nil when the programmer believes the object cannot have value nil, for example when the programmer has forgotten to initialize a variable. Currently, if such an object is added to a set an error will occur. The programmer must then from this point determine why the object has value nil. If sets are modified as proposed no error will occur!!!!!!!!!!! Since there is a bug, someday the programmer will discover there is a problem and after some debugging effort determine that the set contains the element nil (and hopefully recognize that it shouldn't). (S)he must then track down the point that nil was added to the set and thus what object unexpectedly has the value nil. (S)he then is exactly where s(he) would have been right away if Sets report an error on addition of nil. Assuming that nearly all uses of Set do not expect nil to be a possible entry, I propose the following: 1) Add Set method addUnlessNil: object. This method does nothing quietly if object == nil. Otherwise it does add: object. 2) Add Set method addEvenNil: object. This method adds nil to the set in some convoluted way that allows nil to be used for the unused entries in the set. 3) Add any supporting methods such as includesNil and removeNil that might be needed. This proposal is of course UGLY for applications needing to add nil to sets. For example, if one wants to add a collection to a set then one now needs methods addAllEvenNil: and addallUnlessNil:. It does have the following advantages though. a) It is totally backwards compatible. b) There is no performance penalty except when adding nil to a set. c) Situations where nil may be added to a set are clearly marked. Of course my proposal rests on the assumption that nearly all uses of Set do not expect nil to be a possible entry. I believe this to be true. Even if my proposal is not accepted the assumption implies that whatever choice is made should be efficient so as not to penalize all the applications that do not add nil to sets. An interesting side note is that one could argue that my proposal should apply to collections in general. Regardless of how convinced of this one is however, the fact remains that such a change would break a LOT OF CODE (including some of mine) and thus be very difficult to implement in practice. Regards, Ralph Boland -- Volume * Density = Mass. Volume / Density = Intelligence. The latter equation explains the essentially equal intelligence of men and woman and the capabilities of some commonly used operating systems. |
|
|
still no one came up with any good reason to allow nils into sets.
As I said it sounds like much ado about nulls a la : dbdebunk.com viz: http://www.dbdebunk.com/page/page/2928212.htm or http://www.dbdebunk.com/page/page/3317151.htm Like I say, I still have no reall idea why people have this desire to perform hacks based on nulls /me vomits in a corner based on a null or ten million 2009/11/12, Ralph Boland <[hidden email]>: > I appreciate that being able to add nil to a Set is useful. > All the discussion so far seems to be based upon how to > implement such a change efficiently and safely. > > I would like to point out that there is a negative to allowing > nil to be added to a set and as it happens it applies to > every instance of Set I have ever used (at least directly). > > A common bug in programs is to have an object set to nil > when the programmer believes the object cannot have value nil, > for example when the programmer has forgotten to initialize a variable. > > Currently, if such an object is added to a set an error will occur. The > programmer must then from this point determine why the object > has value nil. If sets are modified as proposed no error will > occur!!!!!!!!!!! > Since there is a bug, someday the programmer will discover there is > a problem and after some debugging effort determine that the set contains > the element nil (and hopefully recognize that it shouldn't). (S)he must > then track down the point that nil was added to the set and thus what object > unexpectedly has the value nil. (S)he then is exactly where s(he) would > have > been right away if Sets report an error on addition of nil. > > Assuming that nearly all uses of Set do not expect nil to be a possible > entry, > I propose the following: > > 1) Add Set method addUnlessNil: object. > This method does nothing quietly if object == nil. Otherwise it does > add: object. > > 2) Add Set method addEvenNil: object. > This method adds nil to the set in some convoluted way that allows > nil to be used > for the unused entries in the set. > > 3) Add any supporting methods such as includesNil and removeNil that > might > be needed. > > This proposal is of course UGLY for applications needing to add nil to sets. > For example, if one wants to add a collection to a set then one now needs > methods addAllEvenNil: and addallUnlessNil:. > It does have the following advantages though. > a) It is totally backwards compatible. > b) There is no performance penalty except when adding nil to a set. > c) Situations where nil may be added to a set are clearly marked. > > Of course my proposal rests on the assumption that > nearly all uses of Set do not expect nil to be a possible entry. > I believe this to be true. > Even if my proposal is not accepted the assumption implies that whatever > choice is made should be efficient so as not to penalize all the > applications > that do not add nil to sets. > > An interesting side note is that one could argue that my proposal should > apply > to collections in general. Regardless of how convinced of this one is > however, > the fact remains that such a change would break a LOT OF CODE > (including some of mine) and thus be very difficult to implement in > practice. > Regards, > > Ralph Boland > > -- > Volume * Density = Mass. > Volume / Density = Intelligence. > The latter equation explains the > essentially equal intelligence of men and woman > and the capabilities of some commonly used operating systems. > > |
|
|
In reply to this post by Ralph Boland
2009/11/12 Ralph Boland <[hidden email]>:
> I appreciate that being able to add nil to a Set is useful. > All the discussion so far seems to be based upon how to > implement such a change efficiently and safely. > > I would like to point out that there is a negative to allowing > nil to be added to a set and as it happens it applies to > every instance of Set I have ever used (at least directly). > > A common bug in programs is to have an object set to nil > when the programmer believes the object cannot have value nil, > for example when the programmer has forgotten to initialize a variable. > > Currently, if such an object is added to a set an error will occur. The > programmer must then from this point determine why the object > has value nil. If sets are modified as proposed no error will occur!!!!!!!!!!! > Since there is a bug, someday the programmer will discover there is > a problem and after some debugging effort determine that the set contains > the element nil (and hopefully recognize that it shouldn't). (S)he must > then track down the point that nil was added to the set and thus what object > unexpectedly has the value nil. (S)he then is exactly where s(he) would have > been right away if Sets report an error on addition of nil. > You are right, that currently developer expects to see an error if nil been added to set. But i don't agree that adding new sets could make tracking down an error(s) any harder, because see, we having a lot of different collection types, which allow nils from very starting and i never head of anyone complaining that it makes debugging any harder because of nils or any other object which sits in collection(s). This is a double-edged sword and depending on situation, it instead may help tracking down the bugs, as well as make it harder in others. > Assuming that nearly all uses of Set do not expect nil to be a possible entry, > I propose the following: > > 1) Add Set method addUnlessNil: object. > This method does nothing quietly if object == nil. Otherwise it does > add: object. > > 2) Add Set method addEvenNil: object. > This method adds nil to the set in some convoluted way that allows > nil to be used > for the unused entries in the set. > > 3) Add any supporting methods such as includesNil and removeNil that might > be needed. > > This proposal is of course UGLY for applications needing to add nil to sets. > For example, if one wants to add a collection to a set then one now needs > methods addAllEvenNil: and addallUnlessNil:. > It does have the following advantages though. > a) It is totally backwards compatible. > b) There is no performance penalty except when adding nil to a set. > c) Situations where nil may be added to a set are clearly marked. > > Of course my proposal rests on the assumption that > nearly all uses of Set do not expect nil to be a possible entry. > I believe this to be true. Concerning backwards compatibility: i'm not in favor of exploding Set protocol. My proposal is to make two different classes, one which allows nils, other throws an error , as currently does. But again, i don't wanna see references to new globals in code, like: SetWithNils new instead, if user wants to explicitly state what kind of set he prefers to use, he should do it using a message: [Identity]Set withoutNils new or [Identity]Set withNils new and by default Set new should be Set withNils , so later when critical mass will emerge we could see, based on how often it used, if we may simply deprecate #withoutNils and remove obsolete interface from system, or instead leave it as is. > Even if my proposal is not accepted the assumption implies that whatever > choice is made should be efficient so as not to penalize all the applications > that do not add nil to sets. > > An interesting side note is that one could argue that my proposal should apply > to collections in general. Regardless of how convinced of this one is however, > the fact remains that such a change would break a LOT OF CODE > (including some of mine) and thus be very difficult to implement in practice. > Regards, > My image, with applied changes runs as usual, without any immediate blows , which is a good sign that new changes won't break a LOT OF CODE, but only marginally small portion of it. > Ralph Boland > > -- > Volume * Density = Mass. > Volume / Density = Intelligence. > The latter equation explains the > essentially equal intelligence of men and woman > and the capabilities of some commonly used operating systems. > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Russell N Hyer
2009/11/13 Russell N Hyer <[hidden email]>:
> still no one came up with any good reason to allow nils into sets. > if we'd live in ancient ages, we would argue that there is no good reason to have Zero in algebra & arithmetics. http://en.wikipedia.org/wiki/Zero [quote] Records show that the ancient Greeks seemed unsure about the status of zero as a number. They asked themselves, "How can nothing be something?", leading to philosophical and, by the Medieval period, religious arguments about the nature and existence of zero and the vacuum. The paradoxes of Zeno of Elea depend in large part on the uncertain interpretation of zero. [/quote] but since we live in modern ages, i think it will be a pointless discussion right now. Concerning smalltalk. a) Everything is an object b) Collection comment says: I am the abstract superclass of all classes that represent a group of elements. c) Set comment says: I represent a set of objects without duplicates. I can hold anything that responds to #hash and #=, except for nil. don't you see a missing element here, between b) and c) which is: represent a set of objects without duplicates. period? > As I said it sounds like much ado about nulls a la : > > dbdebunk.com > > viz: > > http://www.dbdebunk.com/page/page/2928212.htm > > or > > http://www.dbdebunk.com/page/page/3317151.htm > > Like I say, I still have no reall idea why people have this desire to > perform hacks based on nulls > > /me vomits in a corner based on a null or ten million > > 2009/11/12, Ralph Boland <[hidden email]>: >> I appreciate that being able to add nil to a Set is useful. >> All the discussion so far seems to be based upon how to >> implement such a change efficiently and safely. >> >> I would like to point out that there is a negative to allowing >> nil to be added to a set and as it happens it applies to >> every instance of Set I have ever used (at least directly). >> >> A common bug in programs is to have an object set to nil >> when the programmer believes the object cannot have value nil, >> for example when the programmer has forgotten to initialize a variable. >> >> Currently, if such an object is added to a set an error will occur. The >> programmer must then from this point determine why the object >> has value nil. If sets are modified as proposed no error will >> occur!!!!!!!!!!! >> Since there is a bug, someday the programmer will discover there is >> a problem and after some debugging effort determine that the set contains >> the element nil (and hopefully recognize that it shouldn't). (S)he must >> then track down the point that nil was added to the set and thus what object >> unexpectedly has the value nil. (S)he then is exactly where s(he) would >> have >> been right away if Sets report an error on addition of nil. >> >> Assuming that nearly all uses of Set do not expect nil to be a possible >> entry, >> I propose the following: >> >> 1) Add Set method addUnlessNil: object. >> This method does nothing quietly if object == nil. Otherwise it does >> add: object. >> >> 2) Add Set method addEvenNil: object. >> This method adds nil to the set in some convoluted way that allows >> nil to be used >> for the unused entries in the set. >> >> 3) Add any supporting methods such as includesNil and removeNil that >> might >> be needed. >> >> This proposal is of course UGLY for applications needing to add nil to sets. >> For example, if one wants to add a collection to a set then one now needs >> methods addAllEvenNil: and addallUnlessNil:. >> It does have the following advantages though. >> a) It is totally backwards compatible. >> b) There is no performance penalty except when adding nil to a set. >> c) Situations where nil may be added to a set are clearly marked. >> >> Of course my proposal rests on the assumption that >> nearly all uses of Set do not expect nil to be a possible entry. >> I believe this to be true. >> Even if my proposal is not accepted the assumption implies that whatever >> choice is made should be efficient so as not to penalize all the >> applications >> that do not add nil to sets. >> >> An interesting side note is that one could argue that my proposal should >> apply >> to collections in general. Regardless of how convinced of this one is >> however, >> the fact remains that such a change would break a LOT OF CODE >> (including some of mine) and thus be very difficult to implement in >> practice. >> Regards, >> >> Ralph Boland >> >> -- >> Volume * Density = Mass. >> Volume / Density = Intelligence. >> The latter equation explains the >> essentially equal intelligence of men and woman >> and the capabilities of some commonly used operating systems. >> >> > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
On Fri, 13 Nov 2009, Igor Stasenko wrote:
> You are right, that currently developer expects to see an error if nil > been added to set. I doubt that anyone ever wrote error handling code around #add:. Developers expect that the value they add to a Set is not nil, and they don't expect to get an error at all. > But i don't agree that adding new sets could make tracking down an > error(s) any harder, because see, we having > a lot of different collection types, which allow nils from very > starting and i never head of anyone > complaining that it makes debugging any harder because of nils or any > other object which sits in collection(s). Sets are not ment to be used for error detection. > My proposal is to make two different classes, one which allows nils, > other throws an error , as currently does. > But again, i don't wanna see references to new globals in code, like: > SetWithNils new > > instead, if user wants to explicitly state what kind of set he prefers > to use, he should do it using a message: > > [Identity]Set withoutNils new > or > [Identity]Set withNils new > > and by default > Set new > > should be Set withNils , so later when critical mass will emerge we > could see, based on how often it used, > if we may simply deprecate #withoutNils and remove obsolete interface > from system, or instead leave it as is. > Duplicating the number of set classes sounds like a really bad idea. If changing the current behavior is such a big issue (which I doubt), then we shouldn't change the current behavior. Levente |
|
|
Levente Uzonyi wrote:
> Sets are not meant to be used for error detection. Precisely. The issue is about consistency, not error handling. Take this, for example: Array with: nil. OrderedCollection with: nil. Bag with: nil. Set with: nil. If the first three work, why wouldn't the last? Or this one: (OrderedCollection new) add: nil. (Bag new) add: nil. (Dictionary new) at: nil put: nil. (Set new) add: nil. If the first three work, why doesn't the last one? All of the above claim to be general purpose collections (i.e., contrary to collections that only store certain kinds of objects such as ByteArray or String). In this context it seems just silly that Set wouldn't store nil given that Array, OrderedCollection, Bag, Dictionary can store nil just fine. Cheers, - Andreas |
|
|
In reply to this post by Levente Uzonyi-2
2009/11/13 Levente Uzonyi <[hidden email]>:
> On Fri, 13 Nov 2009, Igor Stasenko wrote: > >> You are right, that currently developer expects to see an error if nil >> been added to set. > > I doubt that anyone ever wrote error handling code around #add:. Developers > expect that the value they add to a Set is not nil, and they don't expect to > get an error at all. > Right. if developer ever considering putting and error catching blocks around some code, it is obvious not around #add:, because its too microscopic level. >> But i don't agree that adding new sets could make tracking down an >> error(s) any harder, because see, we having >> a lot of different collection types, which allow nils from very >> starting and i never head of anyone >> complaining that it makes debugging any harder because of nils or any >> other object which sits in collection(s). > > Sets are not ment to be used for error detection. > Right said! :) >> My proposal is to make two different classes, one which allows nils, >> other throws an error , as currently does. >> But again, i don't wanna see references to new globals in code, like: >> SetWithNils new >> >> instead, if user wants to explicitly state what kind of set he prefers >> to use, he should do it using a message: >> >> [Identity]Set withoutNils new >> or >> [Identity]Set withNils new >> >> and by default >> Set new >> >> should be Set withNils , so later when critical mass will emerge we >> could see, based on how often it used, >> if we may simply deprecate #withoutNils and remove obsolete interface >> from system, or instead leave it as is. >> > > Duplicating the number of set classes sounds like a really bad idea. i am only proposed this to satisfy those who can't imagine having sets containing nils. And given that sets with no nils is specialization of more generic set, it is logical (despite how minor difference is) to have a separate class for that, in same way as we having Set and IdentitySet and so on. So, i'd rather have two classes instead of dubious additional interface in Set. > If changing the current behavior is such a big issue (which I doubt), then we > shouldn't change the current behavior. > > Levente > > -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |