Tweak mainstream in Squeak

Bill Schwab BSchwab at anest.ufl.edu
Tue Jul 11 15:45:48 UTC 2006


Andreas,

I am going to jump in here; apologies if I am out of synch with the
thread.


=================================
Well, if you were me, you would *want* to update. But you would have
noticed that things got so inconsistently broken at the metaclass level
that unless there are major pay-offs, it simply isn't worth the effort.
That's what happened from 3.6 to 3.7. In 3.8 there was a major payoff -
the m17n integration. That's why I then spent the time needed. For 3.9,
from a Tweak POV there isn't that much interesting in there, so rather
than going through the painful porting exercise yet again I'll probably
spend my time on bootstrapping a stable (3.8-based) metaclass kernel
which can be used in parallel to the 3.9 kernel. Which is not
particularly nice but in the absence of any inclination towards stable
APIs the only alternative that I can see.
=================================

One of the great things about Squeak is one's ability to pick a version
and stick with it if appropriate/necessary, but in general, I would
rather benefit from continued development.


=================================
> I have some legacy Seaside applications in ancient 3.6 images that run
> just fine. They rarely change. They simply run fine. I won't port them
> to 3.9 and a recent version of Seaside. These applications don't
> require anything more as it is available in 3.6. However, for new
> applications I take 3.9, I love
> Shout/eCompletion/OmniBrowser/Traits/Pragmas/ToolBuilder/... I like to
> keep up-to-date as long as it improves my productivity.

You're totally missing my point. Let's take one example from your list:
ToolBuilder. Let's say you've got some work that uses it, would you
really expect that in each new Squeak version you have to spend major
effort to port your code to the latest ToolBuilder version? Or wouldn't
you rather expect that there is a stable API that can be used and that
may be extended over time, or even broken, but if it's broken that you
may get some notice about it beforehand? Or, in particular when the
changes get really fundamental, that instead of modifying ToolBuilder
in-place you get the offer to use either ToolBuilder (working the way it
always did) and whatever the brand-new framework of the day is?

I'm curious but is my position in this discussion really so outrageous?
=================================

Agreed about stable APIs in general, and ToolBuilder in particular.  One
can go further by having deprecated features that lurk for a release or
two giving people time to make a smooth conversion.

Now for the controversial part:  I have a concern about Tweak's compiler
extensions.  At STS05, I saw a demo of Tweak's bleeding edge state at
the time, and could not help thinking the extensions were creating an
avoidable complexity, or were at least in the wrong place.  If you want
to simplify life for beginners, then I think you could manage the event
wiring for them w/o forcing it on advanced users.

I wonder whether some of the resistance you sense is regarding Tweak's
design rather than any of your thoughts about frameworks, which seem
quite reasonable to me, at least as far as I have been able to follow
the discussion.

Sincerely,

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029




More information about the Squeak-dev mailing list