initialize and new

VA Smalltalk is a "100% VisualAge compatible" IDE that includes the original VisualAge technology and the popular VA Assist and WidgetKit add-ons.

Moderators: Eric Clayberg, wembley, tc, Diane Engles, solveig

initialize and new

Postby jtuchel » Tue Mar 15, 2011 11:13 pm

Hi there,

IIRC, Instantiations introduced an implementation of Object>>#initialize in 8.0.1 or 8.0.2. This is very convenient and helps save some extra typing, because almost all classes need to implement initialize.

One thing that's missing now is an implementation of Object class>>#new (or maybe in Behavior class, I am not sure), so that you don't have to implement #new as ^super new initialize in (almost) all your classes. This small addition should be harmless but would help save even more time when implementing a new class.

Maybe this could be added to 8.0.4 or 9.0. Or is there an idea behind the omission of #new that I should learn about?

Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: initialize and new

Postby wembley » Tue Mar 22, 2011 5:41 am

Joachim -

While implementing an empty Object>>initialize method is relatively safe when done 'after the fact' (i.e., in V8.x of the product) since its only negative effect can be to hide the fact that your own initialize method is missing, the same cannot be said for new.

First, the question is where to put it. Since Behavior already impements new as a primitive, Object class>>new is the only alternative. If this had been done in V1.0 of VisualAge Smalltalk, there would not be an issue, but now the image is littered with new methods implemented as:
Code: Select all
  ^ super new initialize

What happens when we slip this method in at the root of the Object hierarchy 'after the fact'? Well, let's look at a class that already implements new in the same way. That class now gets double initialized (at least) since the effect of its new method changes from returning super new initialize to returning super new initialize initialize. Now maybe this does nothing but consume a few extra cycles, but since there is no guarantee that the result of executing an initialize method multiple times is idempotent (I've been waiting for years to be able to use that word :) ), it also could lead to changes in behavior and hard-to-debug errors.

I have some (bad) experience with changing things in this area. Once, long ago, I blindly added an initialize method to a class as a class extension. This caused the behavior of subclasses of the class I extended to change depending on whether or not the application containing my class extension was packaged into the runtime image. I now think very carefully before making changes to the base image -- and I still make an occasional mistake anyway.
John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.
Posts: 405
Joined: Mon Oct 16, 2006 3:01 am
Location: Durham, NC

Return to VA Smalltalk 7.0, 7.5 & 8.0

Who is online

Users browsing this forum: No registered users and 1 guest