About KCP and automatic initialize

Ned Konz ned at bike-nomad.com
Mon Sep 15 20:19:15 UTC 2003


On Monday 15 September 2003 11:31 am, ducasse wrote:

> > But the underlying assumption -- that there is in fact something
> > sensible you can do for default initialization across *all*
> > classes -- is what Richard (and I) disagree with.
>
> I do not understand why simply having a better default
> initialization schema that
> let everybody breaks the rule the way he wants is a problem.

So for classes that aren't able to make initialized instances sensibly 
we'd have to override class>>new to remind people that they can't use 
it to make a sane object?

> Come on. We are trying to force anything. Do not tell me that you
> never do X new to get an object
> well initialized. This automatic initialize is one call the
> benchmarks show that this is nearly free.

We have Behavior>>initializedInstance as well:

initializedInstance
	"Answer an instance of the receiver which in some sense is 
initialized.  In the case of Morphs, this will yield an instance that 
can be attached to the Hand after having received the same kind of 
basic initialization that would be obtained from an instance chosen 
from the 'new morph' menu.   Return nil if the receiver is reluctant 
for some reason to return such a thing"

	^ self new

> > Would you suggest that (for instance) a Stream should have a
> > default constructor? Streams only exist to stream over
> > collections, and it makes little sense to create one without
> > having a collection in hand.
>
> I'm not saying that this default constructor is universal. Why
> don't you read what we say?

I just re-read the proposal. As I read it, you'd do this:

* define an empty Object>>initialize method

* define Behavior>>new to do
^self basicNew initialize

* define Behavior>>new: similarly

* remove all the class-side #new methods that just do '^super new 
initialize'.

Have I read it wrong?

Upon re-reading I see that this is a more modest proposal than I'd 
thought, since you aren't requiring that new actually return a 
usefully initialized object.

> > And I question whether the additional code required to make
> > objects useful once instantiated by a default constructor is
> > worth it overall.
>
> Why wouldn't it be? You remove a lot of duplicated idiot code. You
> ensure that
> for simple object you have a place to initialize them.

I guess that my point is really beside your original point. Your 
proposal doesn't change the fact that there are some objects that 
just won't work when returned from a default constructor. And we 
don't have to spend any effort getting them to work unless there's a 
good reason to.

> > Perhaps it would make sense (as has been suggested earlier) to
> > have new learners subclass some class other than Object at first.
> > You could easily add a PedanticObject that behaved exactly
> > according to easily-taught rules (and perhaps also added some
> > support code for easy inspection or interaction) and then later
> > teach the more powerful general concepts.
>
> I do not really understand why you use Pedantic but this is not my
> problem.
> You are free to think that this point is pedantic. 

Sorry to have used that term. I don't think it's pedantic, really. 
Substitute whatever appropriate name.

I do think that your motivations are strongly colored by the 
difficulty of teaching this little bit of Squeak to beginning 
Smalltalkers. There's nothing wrong with that.

> Note that you have also to have also a suclass for Model

Why is that? Just provide the appropriate methods (and perhaps a 
dependents instVar).

> I think that this is really a hack. Do you think that we would lose
> our time for that point.
>
> Then you should explain to me why in the CLOS MOP make-instance
> calls allocate and initialize? may be they were pedantic or may be
> they designed it conciously.
> May be the creation of instance is really allocation followed by
> initialization.

Of course it is.

I can remember getting bit by this particular idiom ('^super new 
initialize') when I was learning Smalltalk.

I think your proposal is something that would help people learn the 
system easier.

How well will it operate with older code? Colin warns of bugs; I can 
see a couple of potential problems that we may be able to detect and 
warn about (or work around?):

(1) old code (re) defines new (and initialize) in derived class, 
causing repeated calls to #initialize:

	MyClass class>>new
		Behavior>>new			"^super new"
			Behavior>>basicNew
			MyClass>>initialize
		MyClass>>initialize		"initialize"

Simple cases (probably the majority of them) could be detected on 
loading, if necessary:
	if a new class defines a class-side #new,
		and it calls both #new and #initialize
			then warn

- old code needs to do something between #basicNew and #initialize

These will also typically provide (re) definitions of #new, so could 
maybe also be diagnosed.

Have you thought about how to handle this kind of problem?

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE



More information about the Squeak-dev mailing list