Apologies if this has been said before; I haven't read all of the comments.
Still, this bears repeating.
Squeak is a software development system.
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 implyies 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 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.
On Wed, 30 Aug 2023 at 01:39,
<squeak-dev-request(a)lists.squeakfoundation.org> wrote:
>
> Send Squeak-dev mailing list submissions to
> squeak-dev(a)lists.squeakfoundation.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> squeak-dev-request(a)lists.squeakfoundation.org
>
> You can reach the person managing the list at
> squeak-dev-owner(a)lists.squeakfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Squeak-dev digest..."
>
> Today's Topics:
>
> 1. Re: Let's discuss the future of Etoys in Squeak 6.1 (and beyond)
> (David T. Lewis)
> 2. Re: Let's discuss the future of Etoys in Squeak 6.1 (and beyond)
> (Marcel Taeumel)
> 3. Re: Let's discuss the future of Etoys in Squeak 6.1 (and beyond)
> (Marcel Taeumel)
> 4. Re: Let's discuss the future of Etoys in Squeak 6.1 (and beyond)
> (Marcel Taeumel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 29 Aug 2023 22:52:34 -0400
> From: "David T. Lewis" <lewis(a)mail.msen.com>
> Subject: [squeak-dev] Re: Let's discuss the future of Etoys in Squeak
> 6.1 (and beyond)
> To: The general-purpose Squeak developers list
> <squeak-dev(a)lists.squeakfoundation.org>
> Message-ID: <20230830025234.GB41726(a)shell.msen.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Aug 29, 2023 at 09:18:10PM -0400, Jim Rosenberg wrote:
> > > So...should we remove Etoys from Trunk at this point?
> >
> > ***WHY***?????????
>
> The rationale is simplicity and comprehension, primarily from the
> point of view of readers of the code in the Squeak image.
>
> I am not advocating anything here WRT Etoys, but I would say that
> the Squeak image needs to be as simple, readable, and understandable
> as possible. Etoys is a wonderful thing but it can add quite a bit
> of cognitive clutter, and that is why the Etoys removal question is
> important.
>
> >
> > You ***DON'T CARE*** about preserving eToys content.
> >
>
> I think that Marcel has introduced this discussion thread because
> he *does* care. I care about it too, and so do most of the other
> people who are going to reply to this thread :-)
>
> > I don't personally use eToys, but I care very much about Squeak as a
> > content-development platform.
>
> I agree :-)
>
> > This kind of speculation I find profoundly alarming.
> >
>
> But no I'm not alarmed. Preserving content (not "code" but real content)
> is important. It is also a hard problem, so I'm not alarmed to have
> that sort of discussion.
>
> Dave
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 30 Aug 2023 09:25:26 +0200
> From: Marcel Taeumel <marcel.taeumel(a)hpi.de>
> Subject: [squeak-dev] Re: Let's discuss the future of Etoys in Squeak
> 6.1 (and beyond)
> To: gettimothy via Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>
> Message-ID: <Mailbird-1b7d3755-0e8f-4f41-a6cf-5d400460a168(a)hpi.de>
> Content-Type: multipart/alternative;
> boundary="----=_NextPart_59183877.409056177443"
>
> Hi Jim --
>
> > I don't personally use eToys, but I care very much about Squeak as a
> > content-development platform.
>
> Same here. As you can see through the change-set I provided, Etoys in its
> current form implies high maintenance effort. It's modularity is poor, having
> Etoys-specific statements all over the place.
>
> > This kind of speculation I find profoundly alarming.
>
> Not sure what you mean by that. We care very much about robustness and
> backwards compatibility. Etoys in its current form makes it very hard to maintain
> relevant modules such as ImageSegment and DataStream.
>
> Best,
> Marcel
> Am 30.08.2023 03:18:32 schrieb Jim Rosenberg <jr(a)amanue.com>:
> > So...should we remove Etoys from Trunk at this point?
>
> ***WHY***?????????
>
> You ***DON'T CARE*** about preserving eToys content.
>
> I don't personally use eToys, but I care very much about Squeak as a
> content-development platform. This kind of speculation I find profoundly
> alarming.
>
> On Tue, 29 Aug 2023 15:47:19 +0200
> Marcel Taeumel via Squeak-dev
> wrote:
>
> > Hi all --
> >
> > Please find attached a change-set that unloads Etoys from Squeak
> > 6.1alpha #22748 (and later).
> >
> > Let us use this artifact to discuss the future of Etoys in Squeak 6.1
> > and beyond. You can use Monticello or the ChangeSorter to take a look at
> > what's needed besides unloading the Etoys package itself. Also check
> > preamble and postscript of the attached change-set.
> >
> > !!! Yes, simply re-loading the Etoys package is not enough to restore
> > basic Etoys functionality. There are several sub-method changes needed
> > for the Etoys integration into the base system.
> >
> >
> > Here is what would still work through the package MorphicExtras:
> > - Games
> > - Sketches and PaintBox
> > - Flaps
> > - CalendarMorph
> > - SpectrumAnalyzerMorph
> >
> > Here is what would still "work" through the package System:
> > - Object storage (ImageSegment etc.)
> > - ProjectLoading
> >
> > Here is what would still work through the package Protocols:
> > - Lexicon tool
> > - Vocabulary framework
> >
> > Here is what would be gone:
> > - Tiles, viewers, and scripts
> > - Players and costumes
> > - Pen trails, Turtles, ...
> > - References, CustomEventsRegistry, ScriptingSystem
> > - Siblings for (Player-only) uni-classes
> > - DeepCopier support for (Player-only) uni-classes
> > - Preferences #noviceMode, #eToyFriendly, and more
> >
> > Note that we still have several Etoys-compatible releases such as Etoys
> > 4/5/6 and Squeak 5.1/5.2/5.3/6.0. Best compatibility is probably with
> > Etoys 5. Most updated base system is probably Squeak 6.0. :-)
> >
> > So...should we remove Etoys from Trunk at this point?
> >
> >
> > Please share your thoughts. And feel free to also report issues with
> > loading/using the attached change-set itself.
> >
> > Best,
> > Marcel
>
>