[etoys-dev] together again

[Jecel Assumpcao Jr]

Göran,

> Regarding a remerge of Squeak and Etoys:
> 
> 1. I do note that this thread is only posted to etoys-dev and not 
> cross-posted to squeak-dev. Of course, checking first with the eToys 
> developers might be a smart move, but I can't help noting it.

As I mentioned in my previous email, I had tried to get this discussion
going on squeak-dev in the begining of this year and would be happy to
move it there. Andreas asked his question in response to another thread
(getting better development tools into the Etoys image) which was just
in this list. And I agree with you that it would be pointless to bring
it up on squeak-dev if the Etoys developers had instead said that they
would prefer to fork, but now we know they like the idea of a merge.

> 2. Calling some Squeak developers "eToys haters" is not an inclusive 
> approach. I don't think there are any real "haters", but I *do* think a 
> large number of Squeakers want the "base platform" to not be "polluted" 
> by eToys specific stuff.

People's reactions to different features varies a lot. Take commit
messages, for example: some people love them, I am slightly annoyed by
them but think they are worth having, others really, really hate them.
Same thing for Traits, Etoys, namespaces and so on. So I agree that
calling someone is an "Etoys hater" is not a good way to start a
rational discussion, but that doesn't mean it isn't true in a very few
cases. I was just pointing out to Andreas that if he expected full
acceptance of this idea on squeak-dev because some people who complained
in the past have moved from Squeak to Pharo, he would find out
otherwise.

> I really like eToys but I have not looked deeply at its implementation 
> and what a "merge" entails. I think a majority of Squeak-dev would like 
> a merge... *IF* it means keeping eToys a separate layer/entity that can 
> load on top of the base.

Note that the official Squeak images already include Etoys. so a merge
would not imply adding that. It would, instead, mean adding lots of
little fixes and some new functionallity (like scaling the screen or the
new navigation bar).

We all agree about how great it would be to have a tiny kernel image
that could load an Etoys layer, but that is not going to happen soon.
People have created scripts in the past that can rip out all the Etoys
stuff but always in such a way that it is a one way street: the result
can't be loaded back in. We know what needs to be done to go beyond that
and have a reloadable layer, but none of us has the time to do it. So
putting this on a roadmap for the near future is sure to lead to
disappointment.

-- Jecel