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, commits@source.squeak.org 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
#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 eliot.miranda@gmail.com wrote:
Hi Chris,
On Fri, Mar 30, 2018 at 3:57 PM, commits@source.squeak.org 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 asqueaker@gmail.com 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 eliot.miranda@gmail.com
wrote:
Hi Chris,
On Fri, Mar 30, 2018 at 3:57 PM, commits@source.squeak.org 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
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 eliot.miranda@gmail.com wrote:
Hi Chris,
On Fri, Apr 13, 2018 at 10:06 AM, Chris Muller asqueaker@gmail.com 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 eliot.miranda@gmail.com wrote:
Hi Chris,
On Fri, Mar 30, 2018 at 3:57 PM, commits@source.squeak.org 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 asqueaker@gmail.com wrote:
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!
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.
On Fri, Apr 13, 2018 at 3:17 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Chris,
On Fri, Apr 13, 2018 at 10:06 AM, Chris Muller asqueaker@gmail.com
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 <
eliot.miranda@gmail.com>
wrote:
Hi Chris,
On Fri, Mar 30, 2018 at 3:57 PM, commits@source.squeak.org 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
squeak-dev@lists.squeakfoundation.org