Dear list
I wanted an array that lazily initialized elements 1 to n when you asked for the nth one. So I ran something like:
SequenceableCollection variableSubclass #Foo ...
When I started a workspace, and tried Foo new: 10, my image hung.
Eventually, I found the problem. The workspace tried to print the answered instance, which resulted in it being sent a do: message to print its elements. This ran the method
SequenceableCollection>>do: aBlock 1 to: self size do: [:index | aBlock value: (self at: index)]
which ran
Collection>>size | tally | tally := 0. self do: [:each | tally := tally + 1]. ^ tally
which sent do:, which sent size, which ...
Is this considered a bug, or a learning experience for new players? ArrayedCollection avoids it by restoring the primitive method for size.
Rodney
On 29.09.2011, at 19:22, Rodney Polkinghorne wrote:
Dear list
I wanted an array that lazily initialized elements 1 to n when you asked for the nth one. So I ran something like:
SequenceableCollection variableSubclass #Foo ...
When I started a workspace, and tried Foo new: 10, my image hung.
Eventually, I found the problem. The workspace tried to print the answered instance, which resulted in it being sent a do: message to print its elements. This ran the method
SequenceableCollection>>do: aBlock 1 to: self size do: [:index | aBlock value: (self at: index)]
which ran
Collection>>size | tally | tally := 0. self do: [:each | tally := tally + 1]. ^ tally
which sent do:, which sent size, which ...
Is this considered a bug, or a learning experience for new players?
The latter. You should not instantiate an abstract class. I don't think there is much that could be done about this.
- Bert -
ArrayedCollection avoids it by restoring the primitive method for size.
Rodney
2011/9/30 Bert Freudenberg bert@freudenbergs.de:
On 29.09.2011, at 19:22, Rodney Polkinghorne wrote:
Dear list
I wanted an array that lazily initialized elements 1 to n when you asked for the nth one. So I ran something like:
SequenceableCollection variableSubclass #Foo ...
When I started a workspace, and tried Foo new: 10, my image hung.
Eventually, I found the problem. The workspace tried to print the answered instance, which resulted in it being sent a do: message to print its elements. This ran the method
SequenceableCollection>>do: aBlock 1 to: self size do: [:index | aBlock value: (self at: index)]
which ran
Collection>>size | tally | tally := 0. self do: [:each | tally := tally + 1]. ^ tally
which sent do:, which sent size, which ...
Is this considered a bug, or a learning experience for new players?
The latter. You should not instantiate an abstract class. I don't think there is much that could be done about this.
- Bert -
But Foo is a concrete class from Rodney, not Abstract. Generally, if the subclass must implement a method, it is expressed with an abstract implementation in the upper level ^self subclassResponsibility
Here, the subclass must implement a message, either #do: or #size but there is no explicit guidance. Personnally I consider this as very bad kernel code if not a bug. Does any subclass really use Collection>>size ?
Nicolas
ArrayedCollection avoids it by restoring the primitive method for size.
Rodney
2011/9/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
2011/9/30 Bert Freudenberg bert@freudenbergs.de:
On 29.09.2011, at 19:22, Rodney Polkinghorne wrote:
Dear list
I wanted an array that lazily initialized elements 1 to n when you asked for the nth one. So I ran something like:
SequenceableCollection variableSubclass #Foo ...
When I started a workspace, and tried Foo new: 10, my image hung.
Eventually, I found the problem. The workspace tried to print the answered instance, which resulted in it being sent a do: message to print its elements. This ran the method
SequenceableCollection>>do: aBlock 1 to: self size do: [:index | aBlock value: (self at: index)]
which ran
Collection>>size | tally | tally := 0. self do: [:each | tally := tally + 1]. ^ tally
which sent do:, which sent size, which ...
Is this considered a bug, or a learning experience for new players?
The latter. You should not instantiate an abstract class. I don't think there is much that could be done about this.
- Bert -
But Foo is a concrete class from Rodney, not Abstract. Generally, if the subclass must implement a method, it is expressed with an abstract implementation in the upper level ^self subclassResponsibility
Here, the subclass must implement a message, either #do: or #size but there is no explicit guidance. Personnally I consider this as very bad kernel code if not a bug. Does any subclass really use Collection>>size ?
OK, I just opened an image to check and only one does: LinkedList. I suggest moving Collection>>size implementation to LinkedList, and replace it with a subclassResponsibility.
Nicolas
Nicolas
ArrayedCollection avoids it by restoring the primitive method for size.
Rodney
On 30.09.2011, at 13:05, Nicolas Cellier wrote:
2011/9/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
2011/9/30 Bert Freudenberg bert@freudenbergs.de:
On 29.09.2011, at 19:22, Rodney Polkinghorne wrote:
Dear list
I wanted an array that lazily initialized elements 1 to n when you asked for the nth one. So I ran something like:
SequenceableCollection variableSubclass #Foo ...
When I started a workspace, and tried Foo new: 10, my image hung.
Eventually, I found the problem. The workspace tried to print the answered instance, which resulted in it being sent a do: message to print its elements. This ran the method
SequenceableCollection>>do: aBlock 1 to: self size do: [:index | aBlock value: (self at: index)]
which ran
Collection>>size | tally | tally := 0. self do: [:each | tally := tally + 1]. ^ tally
which sent do:, which sent size, which ...
Is this considered a bug, or a learning experience for new players?
The latter. You should not instantiate an abstract class. I don't think there is much that could be done about this.
- Bert -
But Foo is a concrete class from Rodney, not Abstract.
No, it's still abstract since he did not override any methods.
Generally, if the subclass must implement a method, it is expressed with an abstract implementation in the upper level ^self subclassResponsibility
Here, the subclass must implement a message, either #do: or #size but there is no explicit guidance. Personnally I consider this as very bad kernel code if not a bug. Does any subclass really use Collection>>size ?
OK, I just opened an image to check and only one does: LinkedList. I suggest moving Collection>>size implementation to LinkedList, and replace it with a subclassResponsibility.
Nicolas
That would be make the intention more clear, agreed.
- Bert -
2011/10/1 Bert Freudenberg bert@freudenbergs.de:
On 30.09.2011, at 13:05, Nicolas Cellier wrote:
2011/9/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
2011/9/30 Bert Freudenberg bert@freudenbergs.de:
On 29.09.2011, at 19:22, Rodney Polkinghorne wrote:
Dear list
I wanted an array that lazily initialized elements 1 to n when you asked for the nth one. So I ran something like:
SequenceableCollection variableSubclass #Foo ...
When I started a workspace, and tried Foo new: 10, my image hung.
Eventually, I found the problem. The workspace tried to print the answered instance, which resulted in it being sent a do: message to print its elements. This ran the method
SequenceableCollection>>do: aBlock 1 to: self size do: [:index | aBlock value: (self at: index)]
which ran
Collection>>size | tally | tally := 0. self do: [:each | tally := tally + 1]. ^ tally
which sent do:, which sent size, which ...
Is this considered a bug, or a learning experience for new players?
The latter. You should not instantiate an abstract class. I don't think there is much that could be done about this.
- Bert -
But Foo is a concrete class from Rodney, not Abstract.
No, it's still abstract since he did not override any methods.
Generally, if the subclass must implement a method, it is expressed with an abstract implementation in the upper level ^self subclassResponsibility
Here, the subclass must implement a message, either #do: or #size but there is no explicit guidance. Personnally I consider this as very bad kernel code if not a bug. Does any subclass really use Collection>>size ?
OK, I just opened an image to check and only one does: LinkedList. I suggest moving Collection>>size implementation to LinkedList, and replace it with a subclassResponsibility.
Nicolas
That would be make the intention more clear, agreed.
- Bert -
Eliot objected that #do: is already abstract at Collection level, so #size does not have to be. An alternative would be to re-implement Sequenceable>>size ^subclassResponsibility
What do others think ?
Nicolas
On 01.10.2011, at 18:33, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2011/10/1 Bert Freudenberg bert@freudenbergs.de:
On 30.09.2011, at 13:05, Nicolas Cellier wrote:
2011/9/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
2011/9/30 Bert Freudenberg bert@freudenbergs.de:
On 29.09.2011, at 19:22, Rodney Polkinghorne wrote:
Dear list
I wanted an array that lazily initialized elements 1 to n when you asked for the nth one. So I ran something like:
SequenceableCollection variableSubclass #Foo ...
When I started a workspace, and tried Foo new: 10, my image hung.
Eventually, I found the problem. The workspace tried to print the answered instance, which resulted in it being sent a do: message to print its elements. This ran the method
SequenceableCollection>>do: aBlock 1 to: self size do: [:index | aBlock value: (self at: index)]
which ran
Collection>>size | tally | tally := 0. self do: [:each | tally := tally + 1]. ^ tally
which sent do:, which sent size, which ...
Is this considered a bug, or a learning experience for new players?
The latter. You should not instantiate an abstract class. I don't think there is much that could be done about this.
- Bert -
But Foo is a concrete class from Rodney, not Abstract.
No, it's still abstract since he did not override any methods.
Generally, if the subclass must implement a method, it is expressed with an abstract implementation in the upper level ^self subclassResponsibility
Here, the subclass must implement a message, either #do: or #size but there is no explicit guidance. Personnally I consider this as very bad kernel code if not a bug. Does any subclass really use Collection>>size ?
OK, I just opened an image to check and only one does: LinkedList. I suggest moving Collection>>size implementation to LinkedList, and replace it with a subclassResponsibility.
Nicolas
That would be make the intention more clear, agreed.
- Bert -
Eliot objected that #do: is already abstract at Collection level, so #size does not have to be. An alternative would be to re-implement Sequenceable>>size ^subclassResponsibility
What do others think ?
I thought that's what you meant :)
Yes, size should be subclass responsibility only for SequenceableCollections, not Collection.
- Bert -
On Sat, Oct 1, 2011 at 9:54 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 01.10.2011, at 18:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/10/1 Bert Freudenberg bert@freudenbergs.de:
On 30.09.2011, at 13:05, Nicolas Cellier wrote:
2011/9/30 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
2011/9/30 Bert Freudenberg bert@freudenbergs.de:
On 29.09.2011, at 19:22, Rodney Polkinghorne wrote:
> Dear list > > I wanted an array that lazily initialized elements 1 to n when you > asked for the nth one. So I ran something like: > > SequenceableCollection variableSubclass #Foo ... > > When I started a workspace, and tried Foo new: 10, my image hung. > > Eventually, I found the problem. The workspace tried to print the > answered instance, which resulted in it being sent a do: message to > print its elements. This ran the method > > SequenceableCollection>>do: aBlock > 1 to: self size do: > [:index | aBlock value: (self at: index)] > > which ran > > Collection>>size > | tally | > tally := 0. > self do: [:each | tally := tally + 1]. > ^ tally > > which sent do:, which sent size, which ... > > Is this considered a bug, or a learning experience for new players?
The latter. You should not instantiate an abstract class. I don't
think there is much that could be done about this.
- Bert -
But Foo is a concrete class from Rodney, not Abstract.
No, it's still abstract since he did not override any methods.
Generally, if the subclass must implement a method, it is expressed with an abstract implementation in the upper level ^self subclassResponsibility
Here, the subclass must implement a message, either #do: or #size but there is no explicit guidance. Personnally I consider this as very bad kernel code if not a bug. Does any subclass really use Collection>>size ?
OK, I just opened an image to check and only one does: LinkedList. I suggest moving Collection>>size implementation to LinkedList, and replace it with a subclassResponsibility.
Nicolas
That would be make the intention more clear, agreed.
- Bert -
Eliot objected that #do: is already abstract at Collection level, so #size does not have to be. An alternative would be to re-implement Sequenceable>>size ^subclassResponsibility
What do others think ?
I thought that's what you meant :)
Yes, size should be subclass responsibility only for SequenceableCollections, not Collection.
and if so this is tricky: SequenceableCollection withAllSubclasses select: [:c| (c whichClassIncludesSelector: #size) == Collection] => an OrderedCollection(SequenceableCollection LinkedList Semaphore)
So if added as a subclass responsibility in SequenceableCollection it must be implemented in LinkedList and Semaphore.
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eliot Miranda -
Nicolas Cellier -
Rodney Polkinghorne