Chris Muller uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-cmm.785.mcz ==================== Summary ==================== Name: Collections-cmm.785 Author: cmm Time: 30 March 2018, 5:57:37.727038 pm UUID: 37e9870a-5379-4185-8538-fada710dad5d Ancestors: Collections-eem.784 Add #at:ifPresent:ifAbsent: for API compatibility with other kinds of directly-accessible Collections. =============== Diff against Collections-eem.784 =============== Item was added: + ----- Method: SequenceableCollection>>at:ifPresent:ifAbsent: (in category 'accessing') ----- + at: index ifPresent: elementBlock ifAbsent: exceptionBlock + "Answer the value of elementBlock on the element at position index. If I do not contain an element at index, answer the result of evaluating exceptionBlock." + ^ elementBlock value: + (self + at: index + ifAbsent: [ ^ exceptionBlock value ])! |
Hi Chris,
On Fri, Mar 30, 2018 at 3:57 PM, <[hidden email]> wrote: Chris Muller uploaded a new version of Collections to project The Trunk: I'm thinking that this sits better in Collection as a default implementation. I note that also we don't have a subclass responsibility implementations of at:ifAbsent: (and maybe others) in Collection. _,,,^..^,,,_ best, Eliot |
#do: is currently the only method which any subclass of Collection is
required to implement in order to inherit all of the other behaviors. #at:, et al, are "direct access" methods which are not required for Collections and, in cases like Set, not even *supported*, so we would probably need to duplicate various #shouldNotImplement's overrides in Set and possibly other subclasses. That would leave the superclass saying, "subclassResponsibility" and the subclasses saying, "shouldNotImplement", which feels conflicted. I think is one of those cases where a little duplication of the #at: method(s) is worth it so we don't have to explicitly delete the behavior. On Thu, Apr 12, 2018 at 12:15 PM, Eliot Miranda <[hidden email]> wrote: > Hi Chris, > > On Fri, Mar 30, 2018 at 3:57 PM, <[hidden email]> wrote: >> >> Chris Muller uploaded a new version of Collections to project The Trunk: >> http://source.squeak.org/trunk/Collections-cmm.785.mcz >> >> ==================== Summary ==================== >> >> Name: Collections-cmm.785 >> Author: cmm >> Time: 30 March 2018, 5:57:37.727038 pm >> UUID: 37e9870a-5379-4185-8538-fada710dad5d >> Ancestors: Collections-eem.784 >> >> Add #at:ifPresent:ifAbsent: for API compatibility with other kinds of >> directly-accessible Collections. >> >> =============== Diff against Collections-eem.784 =============== >> >> Item was added: >> + ----- Method: SequenceableCollection>>at:ifPresent:ifAbsent: (in >> category 'accessing') ----- >> + at: index ifPresent: elementBlock ifAbsent: exceptionBlock >> + "Answer the value of elementBlock on the element at position >> index. If I do not contain an element at index, answer the result of >> evaluating exceptionBlock." >> + ^ elementBlock value: >> + (self >> + at: index >> + ifAbsent: [ ^ exceptionBlock value ])! > > > I'm thinking that this sits better in Collection as a default > implementation. I note that also we don't have a subclass responsibility > implementations of at:ifAbsent: (and maybe others) in Collection. > _,,,^..^,,,_ > best, Eliot > > > |
Hi Chris,
On Fri, Apr 13, 2018 at 10:06 AM, Chris Muller <[hidden email]> wrote: #do: is currently the only method which any subclass of Collection is Oops, you're right! So I'm wrong to suggest it. Ignore the suggestion. Arguably there should be an IndexableCollection abstract class below Collection that is the shared superclass for Dictionary, SequenceableCollection, Bitset et al. Alas, HashedCollection is an implementation class that exists to share hash access implementation between Dictionary and Set et al. So this prevents the idea. HashedCollection would be better as a stageful trait. But that's a different discussion ;-)
_,,,^..^,,,_ best, Eliot |
Well, I hope this is not something you plan to spend your great talent
and time on, Squeak needs you for so much more. :) Messing with the HashedCollection hierarchy or making it dependent on stateful traits would be somewhere between drastic to disastrous for me. When Magma clients establish a connection to a server, a "class map" is downloaded, which informs the client the Integer id of each class in the model. But, to even do that handshake, a few "hardcoded" minimumClasses are needed, one of which is Dictionary, which now depends on HashedCollection (but didn't always). When that update was made to the hierarchy, I had to make tedious and undesirable changes to Magma to ensure compatibility with models created prior to that, because of the way the set of minimumClasses needs to be calculated. Fighting complexity-creep is a battle for every language and project but, honorably, Squeak has mostly kept its beauty and simplicity; which are self-reinforcing properties! On Fri, Apr 13, 2018 at 3:17 PM, Eliot Miranda <[hidden email]> wrote: > Hi Chris, > > On Fri, Apr 13, 2018 at 10:06 AM, Chris Muller <[hidden email]> wrote: >> >> #do: is currently the only method which any subclass of Collection is >> required to implement in order to inherit all of the other behaviors. >> #at:, et al, are "direct access" methods which are not required for >> Collections and, in cases like Set, not even *supported*, so we would >> probably need to duplicate various #shouldNotImplement's overrides in >> Set and possibly other subclasses. That would leave the superclass >> saying, "subclassResponsibility" and the subclasses saying, >> "shouldNotImplement", which feels conflicted. I think is one of those >> cases where a little duplication of the #at: method(s) is worth it so >> we don't have to explicitly delete the behavior. > > > Oops, you're right! So I'm wrong to suggest it. Ignore the suggestion. > Arguably there should be an IndexableCollection abstract class below > Collection that is the shared superclass for Dictionary, > SequenceableCollection, Bitset et al. Alas, HashedCollection is an > implementation class that exists to share hash access implementation between > Dictionary and Set et al. So this prevents the idea. HashedCollection > would be better as a stageful trait. But that's a different discussion ;-) > >> On Thu, Apr 12, 2018 at 12:15 PM, Eliot Miranda <[hidden email]> >> wrote: >> > Hi Chris, >> > >> > On Fri, Mar 30, 2018 at 3:57 PM, <[hidden email]> wrote: >> >> >> >> Chris Muller uploaded a new version of Collections to project The >> >> Trunk: >> >> http://source.squeak.org/trunk/Collections-cmm.785.mcz >> >> >> >> ==================== Summary ==================== >> >> >> >> Name: Collections-cmm.785 >> >> Author: cmm >> >> Time: 30 March 2018, 5:57:37.727038 pm >> >> UUID: 37e9870a-5379-4185-8538-fada710dad5d >> >> Ancestors: Collections-eem.784 >> >> >> >> Add #at:ifPresent:ifAbsent: for API compatibility with other kinds of >> >> directly-accessible Collections. >> >> >> >> =============== Diff against Collections-eem.784 =============== >> >> >> >> Item was added: >> >> + ----- Method: SequenceableCollection>>at:ifPresent:ifAbsent: (in >> >> category 'accessing') ----- >> >> + at: index ifPresent: elementBlock ifAbsent: exceptionBlock >> >> + "Answer the value of elementBlock on the element at position >> >> index. If I do not contain an element at index, answer the result of >> >> evaluating exceptionBlock." >> >> + ^ elementBlock value: >> >> + (self >> >> + at: index >> >> + ifAbsent: [ ^ exceptionBlock value ])! >> > >> > >> > I'm thinking that this sits better in Collection as a default >> > implementation. I note that also we don't have a subclass >> > responsibility >> > implementations of at:ifAbsent: (and maybe others) in Collection. >> > _,,,^..^,,,_ >> > best, Eliot > > > _,,,^..^,,,_ > best, Eliot > > > |
On Fri, Apr 13, 2018 at 3:46 PM, Chris Muller <[hidden email]> wrote: Well, I hope this is not something you plan to spend your great talent Rest assured, I'm with you there. My comment on HashedCollection and stateful traits was more along the lines of "let's not pursue this because if we did we'd have to use stageful traits" than a proposal. Pulling in stageful traits for this is getting one's priorities hopelessly mixed up I think.
_,,,^..^,,,_ best, Eliot |
Free forum by Nabble | Edit this page |