No, for classes where it makes no sense you would not implement 
initialize (meaning everything is nill-ed, as it is now). ?! I do not 
get in the whole of this discussion why everybody assumes that as soon 
we implement an initialize on Object, everybody ***has*** to override 
it to provide perfect good values. This is NOT the goal of the 
proposition.

For example, I personally strongly prefer lazy initialization for most 
of my things, so I will only override the initialize method 
occasionely, just using it to initialize variables that I really want 
set. But I want then the flexibility to just have to override this 
initialize method and use that feature. It *adds* to my comfort. And 
likewise for those classes for which you do not want or cannot use a 
parameterless initialize. Do not use it. <sigh>I do not get it. I have 
the impression that we are not making ourselves clear here....

On Monday, Sep 15, 2003, at 22:19 Europe/Zurich, Ned Konz wrote:

> 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
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org