[squeak-dev] 4.5 -- how should we proceed then?

Frank Shearar frank.shearar at gmail.com
Mon Dec 23 17:56:52 UTC 2013


On 23 December 2013 17:31, Chris Muller <ma.chris.m at gmail.com> wrote:
> It's fascinating how my compadres whom I've known on-line for so long
> would stretch their logic so thin just to pile-on Chris.
>
> I'm kind of stunned.  I'm just trying to get 4.5 ready and asking for
> help with Environments because that's what's been holding up the
> release.  I have little interest in Environments myself, but after no
> progress for the last two months, I figure for the sake of the release
> I'll work to fix it up myself.

And I appreciate it - your first touching of the Environment code -
making that unit test pass - spurred me on to actually try use it. As
a result, we have a first draft of loading Monticello definitions into
an Environment, and it's your commit (Monticello-cmm.579) that started
the ball rolling.

I don't know quite what you mean by "no progress": I don't know if you
mean around Environments, or around fixing bugs in 4.5. We've
certainly made a fair amount of progress in untangling module
dependencies!

Why do you think Environments is holding up the release? No one is
seriously using Environments yet, so if we released 4.5 right now, no
one would run into the limitations the tooling (Browser, etc) have
around Environments.

> This VERY FIRST tiny little refactoring improvement simply to help me
> read and understand the code, and bring it to consistent standard and
> quality with the rest of the image, is met with confused resistance
> from Frank.  He _totally_ misunderstood and misstated what was being
> done (he thought it was set:, set:, set:, which is wrong).  Suddenly,
> Colin is alive and jumps in with "Frank is right" and confirms his own
> mutual mis-understanding.  After banging my head on the wall for 3
> days showing why Frank was NOT right, now Levente piles on.

I'm sorry that you feel that way, Chris. I find your taste in UI
design impeccable. I just happen to disagree with part of the changes
in Environments.

> Do you all understand you're actually fighting to _defactor_ the code?
>  My god who are you poeple?!
>
> I thought we had settled this issue about #new and #initailize YEARS
> ago!  Let's see, yep.  Behavior>>#new:
>
>    "Noury Bouraqadi 8/23/2003 14:51 · instance creation · 93
> implementors · in no change set · "
>
> But hey, if you guys want to lurch back to 2002 and your code repeat
> itself over and over again with ^self basicNew initializeWith... or
> ^self basicNew initialize in every constructor, go right ahead.
> There's nothing like "standards" especially when there are so many to
> choose from, huh?

Do you mean "initialize" or "initializeWithSomething" in the "in every
constructor" part? Because as has been said a few times, _you don't
call initialize all over the place_. You call it _once_, from your
#initializeWith:all:the:things:.

It would be a very sad state of affairs if best practice didn't ever
improve! And I view the basicNew initializeWith: idiom _as_ an
improvement, because it makes it clear that you have, halfway through
the process, a semi/uninitialised object. If I could, I'd get rid of
setters entirely, and you could only ever construct a valid object.
Smalltalk just doesn't work that way, and you can only set instvars
through setting a message, so I make do with the closest I can get:
basicNew initializeWith:.

> I just want to make progress on 4.5.  Am I the only one?  Now I feel
> handcuffed -- so what now?

I can sympathise with your feelings of frustration. What stops you
from simply doing other stuff on 4.5? There's oodles to do. I wouldn't
mind some playing with Monticello-fbs.581 in the Inbox: getting that
working will also flush out Environment bugs.

One thing no one's ever discussed yet, and an area in which you happen
to excel, is thinking about how the tools should look when dealing
with Environments. For instance, if you import the Control package
into an Environment, and browse something in that package -
DelimitedDynamicVariable, say - the Browser shows only that
Environment. It doesn't show any imported classes. Is this a good
thing? If we should see imported classes, how should we indicate the
declared versus referenced classes in the tooling?

But if you feel like you've hit a complete brick wall, why not switch
focus for a while? Grab one of the other things we want for 4.5, and
hack on that. Or squash a bug on bugs.squeak.org.

frank


More information about the Squeak-dev mailing list