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

Frank Shearar frank.shearar at gmail.com
Mon Dec 23 22:41:22 UTC 2013


On 23 December 2013 21:43, Chris Muller <asqueaker at gmail.com> wrote:
>>> 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:.
>
> But there are initializeWith:all:the:things: method in each class
> (that have parameterized constructors).  You don't get call that
> "once".  "Once" means, truly, just _ONCE_ for all classes.  Uno.  From
> Behavior>>#new.

I fail to see how that (#initialize only ever being called from
Behaviour>>#new) is useful. #initialize can't initialise an object
properly, because it doesn't have the info that the constructor
methods give.

Setting these instvars post initialisation is, in my opinion, a smell.

Because "initialisation" in my book means setting the instvars of an
instance to the values they should be: "initialise a Point" means
setting its x and y instvars, for instance. #initialize cannot do
this, so is largely useless except in the rather special case of inst
vars not being set by constructor methods. (A class that memoised
calls might initialise its cache to Dictionary new, for instance.)

> "Once per class" is exactly what I mean by, "from all over the place".
>  It denies to newbies reading class-side Constructor Methods that we
> have resolved this issue about how default values of inst-vars (not
> constructor parameters) should be initialized.

You'll need to explain further what you mean here. I don't understand
what the distinction between default value of inst vars and of
constructor parameters might be. I guess you're saying that the
default values of instvars get set in #initialize while the default
values of constructor parameters are set by the way the various
constructor methods call each other? In that case my counterargument
is to not set the instvars in #initialize because you set them twice.

>> It would be a very sad state of affairs if best practice didn't ever
>> improve!
>
> It's obvious you don't know me well when you think you have to tell me
> that.  I'm the most rebellious one here..  :)

I suspect we might be fighting for that prize!

>> 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.
>
> You mention setters again but a Constructor Parameter Method is no
> more a "setter" than a #printString is an "accessor".

The reason I keep dissing them as setters is because they only set
_some_ state. Now, granted, some like Point >> #setX:setY: happen to
fully initialize an instance, but the name does not make this
responsibility clear. But (the nonexistent) Point >>
#initializeWithX:y: tells you loudly and clearly that the method
initialises the instance. That "#initializeWithX:y" is ugly to look at
and painful to type is just gravy: you shouldn't be calling that
method anyway. (Scala's type check is called isInstanceOf, and its
cast operation called asInstanceOf, are named this way precisely as a
source of pain to make you think twice about doing the wrong thing.)

> Smalltalk's simplicity and unity means we have to rely more on
> _conventions_, rather than language constructs, to delineate our
> pattern language.

Sure.

>> 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.
>
> My interest in is in getting the 4.5 _release_ done ASAP.  The only
> tests which are faliing at this point seem to be the Environments ones
> and a couple of Obsolete classes I think.  That's what led me here.

Some tests will take a long time to get working: the exception handler
one, for instance. I _dislike_ making a release with failing tests,
but we're just not going to get a green light on the test suite within
any reasonable release window, without faking it through
expectedFailures.

There's only one failing Environment test, and that's the same kind of
failing test as the exception handler one: it's a marker for the later
stage of development. Environments work: all that test does is tell us
that there's work to do to load MC definitions into an Environment.

frank


More information about the Squeak-dev mailing list