Apologies if this has been said before; I haven't read all of the comments. Apologies if this has been said before; I haven't read all of the comments. Still, this bears repeating. Squeak is a software development environment. EToys is an application that uses Squeak.
As such when EToys finds that a Squeak method doesn't do what EToys needs then EToys should create a subclass of the class containing the method and create its version of the method in the subclass. I have had to do this many times.
I realize this approach can sometimes be complicated because wherever the subclass is to be created is a method that must also be modified. This implies that a new subclass of the class containing the subclass creating method must also be created. This can be a real nightmare and I expect would be so for EToys. But EToys gains the advantage of not needing a fork of Squeak to proceed and Squeak gains the advantage of not using any EToys code. Remember that Pharo was created in part because its supporters didn't believe EToys should be part of Squeak.
This is how OO software applications should be developed and I don't understand why ETorys was instead developed the way it was.
If it is a performance issue then replacing a method directly, as done in EToys, should only be done where the need for the performance gain is demonstrated.
"If you are not an expert don't optimize; if you are an expert don't optimize yet."
I don't know who said this but somebody did.
Ralph
I am also not reading all comments... And it seems that there are two strands discussed here. One is to make the Etoys system loadable unloadable from Squeak, which is a worthy goal and can be done. But I am interested more in how to make modular software.
I wrote about pluggable and dynamically editable object extension mechanism here: https://croquet.io/blog/april2022/microverse/ which draws upon a lot from my experiences in Etoys and other systems. Most notably, something like Traits (but for objects) could have been used to implement cleaner Etoys.
But then, the original implementor had some time constraint, and not particularly interested in a new object system altogether... And Morphic for Squeak got a bit of "oh, this time let us try something else" mind set, as the original version was done in Self, and then John wanted to make more classes for Sqeuak version of Morphic (thus we have BorderedMorph and RectnagleMorph and those), and crucially Morphic was not designed to support Etoys. That would have been really good.
On Thu, Aug 31, 2023 at 5:55 PM Ralph Boland rpboland@gmail.com wrote:
Apologies if this has been said before; I haven't read all of the comments. Apologies if this has been said before; I haven't read all of the comments. Still, this bears repeating. Squeak is a software development environment. EToys is an application that uses Squeak.
As such when EToys finds that a Squeak method doesn't do what EToys needs then EToys should create a subclass of the class containing the method and create its version of the method in the subclass. I have had to do this many times.
I realize this approach can sometimes be complicated because wherever the subclass is to be created is a method that must also be modified. This implies that a new subclass of the class containing the subclass creating method must also be created. This can be a real nightmare and I expect would be so for EToys. But EToys gains the advantage of not needing a fork of Squeak to proceed and Squeak gains the advantage of not using any EToys code. Remember that Pharo was created in part because its supporters didn't believe EToys should be part of Squeak.
This is how OO software applications should be developed and I don't understand why ETorys was instead developed the way it was.
If it is a performance issue then replacing a method directly, as done in EToys, should only be done where the need for the performance gain is demonstrated.
"If you are not an expert don't optimize; if you are an expert don't optimize yet."I don't know who said this but somebody did.
Ralph
squeak-dev@lists.squeakfoundation.org
-
Ralph Boland -
Yoshiki Ohshima