Does it make sense to have 5 of the 9 nil-testing methods on
ProtoObject, and the remaining 4 on Object? It seems like the various forms of nil-testing are something any code should feel free to do. I think we should move the remaining 4 to ProtoObject. On Fri, Oct 25, 2013 at 5:38 PM, <[hidden email]> wrote: > Levente Uzonyi uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-ul.542.mcz > > ==================== Summary ==================== > > Name: Collections-ul.542 > Author: ul > Time: 26 October 2013, 12:22:26.493 am > UUID: e52fefbe-fb04-46f4-a956-f7bbcb5c8965 > Ancestors: Collections-cmm.541 > > Make Dictionary >> #includesKey: more lightweight. > > =============== Diff against Collections-cmm.541 =============== > > Item was changed: > ----- Method: Dictionary>>includesKey: (in category 'testing') ----- > includesKey: key > "Answer whether the receiver has a key equal to the argument, key." > > + ^(array at: (self scanFor: key)) ~~ nil "We could use #notNil here, but ProtoObject doesn't understand it."! > - self at: key ifAbsent: [^false]. > - ^true! > > |
On Sat, 26 Oct 2013, Chris Muller wrote:
> Does it make sense to have 5 of the 9 nil-testing methods on > ProtoObject, and the remaining 4 on Object? It seems like the various > forms of nil-testing are something any code should feel free to do. > > I think we should move the remaining 4 to ProtoObject. It depends on the role of ProtoObject and Object. Which are those methods? Levente > > > On Fri, Oct 25, 2013 at 5:38 PM, <[hidden email]> wrote: >> Levente Uzonyi uploaded a new version of Collections to project The Trunk: >> http://source.squeak.org/trunk/Collections-ul.542.mcz >> >> ==================== Summary ==================== >> >> Name: Collections-ul.542 >> Author: ul >> Time: 26 October 2013, 12:22:26.493 am >> UUID: e52fefbe-fb04-46f4-a956-f7bbcb5c8965 >> Ancestors: Collections-cmm.541 >> >> Make Dictionary >> #includesKey: more lightweight. >> >> =============== Diff against Collections-cmm.541 =============== >> >> Item was changed: >> ----- Method: Dictionary>>includesKey: (in category 'testing') ----- >> includesKey: key >> "Answer whether the receiver has a key equal to the argument, key." >> >> + ^(array at: (self scanFor: key)) ~~ nil "We could use #notNil here, but ProtoObject doesn't understand it."! >> - self at: key ifAbsent: [^false]. >> - ^true! >> >> > > |
In reply to this post by Chris Muller-3
On Sat, Oct 26, 2013 at 02:28:10PM -0500, Chris Muller wrote:
> Does it make sense to have 5 of the 9 nil-testing methods on > ProtoObject, and the remaining 4 on Object? It seems like the various > forms of nil-testing are something any code should feel free to do. > > I think we should move the remaining 4 to ProtoObject. I don't think that *anything* should go into ProtoObject unless it absolutely needs to be there. Period. ProtoObject is intended to be minimal, and we should take care to keep it so. Dave |
In reply to this post by Levente Uzonyi-2
Well, ok, since ifNotNilDo: is on its way to deprecation anyway,
perhaps really it's just #notNil that's left missing in ProtoObject. That and #isEmptyOrNil too, because it seems unlikely anythiing would override that with something different. On Sat, Oct 26, 2013 at 3:11 PM, Levente Uzonyi <[hidden email]> wrote: > On Sat, 26 Oct 2013, Chris Muller wrote: > >> Does it make sense to have 5 of the 9 nil-testing methods on >> ProtoObject, and the remaining 4 on Object? It seems like the various >> forms of nil-testing are something any code should feel free to do. >> >> I think we should move the remaining 4 to ProtoObject. > > > It depends on the role of ProtoObject and Object. Which are those methods? > > > Levente > > >> >> >> On Fri, Oct 25, 2013 at 5:38 PM, <[hidden email]> wrote: >>> >>> Levente Uzonyi uploaded a new version of Collections to project The >>> Trunk: >>> http://source.squeak.org/trunk/Collections-ul.542.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Collections-ul.542 >>> Author: ul >>> Time: 26 October 2013, 12:22:26.493 am >>> UUID: e52fefbe-fb04-46f4-a956-f7bbcb5c8965 >>> Ancestors: Collections-cmm.541 >>> >>> Make Dictionary >> #includesKey: more lightweight. >>> >>> =============== Diff against Collections-cmm.541 =============== >>> >>> Item was changed: >>> ----- Method: Dictionary>>includesKey: (in category 'testing') ----- >>> includesKey: key >>> "Answer whether the receiver has a key equal to the argument, >>> key." >>> >>> + ^(array at: (self scanFor: key)) ~~ nil "We could use #notNil >>> here, but ProtoObject doesn't understand it."! >>> - self at: key ifAbsent: [^false]. >>> - ^true! >>> >>> >> >> > |
In reply to this post by David T. Lewis
Take a gander at the API of ProtoObject by arrowing through the
categories/protocols, one by one. It's pretty clean, and I think everything we have there qualifies as "absolutely needs", don't you? But the one that's missing is #notNil. I mean, we've got #ifNil: and #ifNotNil:. We've got #isNil but not #notNil. Proxy code should be able to reliably use notNil as much as isNil rather than setting a trap. No one will ever override notNil.. On Sat, Oct 26, 2013 at 3:43 PM, David T. Lewis <[hidden email]> wrote: > On Sat, Oct 26, 2013 at 02:28:10PM -0500, Chris Muller wrote: >> Does it make sense to have 5 of the 9 nil-testing methods on >> ProtoObject, and the remaining 4 on Object? It seems like the various >> forms of nil-testing are something any code should feel free to do. >> >> I think we should move the remaining 4 to ProtoObject. > > I don't think that *anything* should go into ProtoObject unless it > absolutely needs to be there. Period. > > ProtoObject is intended to be minimal, and we should take care to > keep it so. > > Dave > > |
In reply to this post by David T. Lewis
On Sat, 26 Oct 2013, David T. Lewis wrote:
> On Sat, Oct 26, 2013 at 02:28:10PM -0500, Chris Muller wrote: >> Does it make sense to have 5 of the 9 nil-testing methods on >> ProtoObject, and the remaining 4 on Object? It seems like the various >> forms of nil-testing are something any code should feel free to do. >> >> I think we should move the remaining 4 to ProtoObject. > > I don't think that *anything* should go into ProtoObject unless it > absolutely needs to be there. Period. > > ProtoObject is intended to be minimal, and we should take care to > keep it so. I agree with that, but most of the nil-testing protocol is already there. And there's some asymmetry because of #isNil and #notNil. So adding another method wouldn't make the situation worse, but it would unify the system. Levente > > Dave > > > |
In reply to this post by Chris Muller-3
+1
You are right. Dave On Sat, Oct 26, 2013 at 04:10:23PM -0500, Chris Muller wrote: > Take a gander at the API of ProtoObject by arrowing through the > categories/protocols, one by one. > > It's pretty clean, and I think everything we have there qualifies as > "absolutely needs", don't you? > > But the one that's missing is #notNil. I mean, we've got #ifNil: and > #ifNotNil:. We've got #isNil but not #notNil. Proxy code should be > able to reliably use notNil as much as isNil rather than setting a > trap. No one will ever override notNil.. > > On Sat, Oct 26, 2013 at 3:43 PM, David T. Lewis <[hidden email]> wrote: > > On Sat, Oct 26, 2013 at 02:28:10PM -0500, Chris Muller wrote: > >> Does it make sense to have 5 of the 9 nil-testing methods on > >> ProtoObject, and the remaining 4 on Object? It seems like the various > >> forms of nil-testing are something any code should feel free to do. > >> > >> I think we should move the remaining 4 to ProtoObject. > > > > I don't think that *anything* should go into ProtoObject unless it > > absolutely needs to be there. Period. > > > > ProtoObject is intended to be minimal, and we should take care to > > keep it so. > > > > Dave > > > > |
In reply to this post by David T. Lewis
> I don't think that *anything* should go into ProtoObject unless it
> absolutely needs to be there. Period. > > ProtoObject is intended to be minimal, and we should take care to > keep it so. +1 Stef --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com |
Free forum by Nabble | Edit this page |