Is this considered a bug, or a learning experience for new players?
By "this", I meant the consequence of my error (expected "Error: Foo needs a method for size", got a hung image), and the effort required to find its cause. I agree with Eliot's suggestion, that SequenceableCollection>>size should raise an error.
You should not instantiate an abstract class.
To follow that advice, I'd need a way to find out which classes were abstract, and when I'd implemented enough methods to stop them being abstract. That seems to be a black art in Smalltalk.
There are two ways I could have written this. One is to define a subclass of Collection, and use the built-in collect:, inject:into: and so on. The other is to subclass Object, and define the iterators that I was going to use. Which approach is more common?
Rodney
On Sun, Oct 2, 2011 at 10:51 PM, Rodney Polkinghorne rpolkinghorne@groupwise.swin.edu.au wrote:
You should not instantiate an abstract class.
To follow that advice, I'd need a way to find out which classes were abstract, and when I'd implemented enough methods to stop them being abstract. That seems to be a black art in Smalltalk.
Yes, the way this is supposed to work is that you look for subclassResponsibility: methods and override them. That is why #size in Collection is wrong; it hides what you are supposed to do.
So, one more vote for fixing this.
-Ralph
On Sun, Oct 2, 2011 at 8:51 PM, Rodney Polkinghorne < rpolkinghorne@groupwise.swin.edu.au> wrote:
Is this considered a bug, or a learning experience for new players?
By "this", I meant the consequence of my error (expected "Error: Foo needs a method for size", got a hung image), and the effort required to find its cause. I agree with Eliot's suggestion, that SequenceableCollection>>size should raise an error.
You should not instantiate an abstract class.
To follow that advice, I'd need a way to find out which classes were abstract, and when I'd implemented enough methods to stop them being abstract. That seems to be a black art in Smalltalk.
There are two ways I could have written this. One is to define a subclass of Collection, and use the built-in collect:, inject:into: and so on. The other is to subclass Object, and define the iterators that I was going to use. Which approach is more common?
The former is the one that makes sense. Why reinvent the wheel? The Collection hierarchy is designed to be both used and reused (subclassed). Copy-paste merely wastes space, makes the system more complex, and harder to maintain.
Rodney
2011/10/3 Eliot Miranda eliot.miranda@gmail.com:
On Sun, Oct 2, 2011 at 8:51 PM, Rodney Polkinghorne rpolkinghorne@groupwise.swin.edu.au wrote:
Is this considered a bug, or a learning experience for new players?
By "this", I meant the consequence of my error (expected "Error: Foo needs a method for size", got a hung image), and the effort required to find its cause. I agree with Eliot's suggestion, that SequenceableCollection>>size should raise an error.
You should not instantiate an abstract class.
To follow that advice, I'd need a way to find out which classes were abstract, and when I'd implemented enough methods to stop them being abstract. That seems to be a black art in Smalltalk.
There are two ways I could have written this. One is to define a subclass of Collection, and use the built-in collect:, inject:into: and so on. The other is to subclass Object, and define the iterators that I was going to use. Which approach is more common?
The former is the one that makes sense. Why reinvent the wheel? The Collection hierarchy is designed to be both used and reused (subclassed). Copy-paste merely wastes space, makes the system more complex, and harder to maintain.
That's true, that's why I think that my first proposition of having both #size and #do: abstract was a bit lighter (no duplication required).
Nicolas
Rodney
-- best, Eliot
squeak-dev@lists.squeakfoundation.org