> 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?
Yes in a similar way that you forbid new now if you do not want to have 
instance created using new
I guess that this is the same.

>> 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

I know but nobody use it. :)

>
>>> 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?

Yes. No more. this is the minimal change we can do to offer a simple, 
intuitive
default initialize protocol.

> 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.

Exact.
We just propose a hook so that people can get initialize instance if 
they want
without having to mess up with the meta level.

>>> 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.

Exact! nothing is free our proposal is not about class invariants or
other things I respect. but this is not the point. The point is to have 
a
simple hook method that provide a default mechanism that anybody can 
violate
if they really want.

>>> 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.

Ok done.

> 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.

or even not so young people.
Something that strikes when I arrived in Squeak is that a fluent guy (I 
do not want to blame him)
asked the following question: I wanted to see how new: was working as 
in Array new: 4
so I looked in the superclass of Array. I saw that and thought that we 
have a lot of work to do
to explain meta to people. I was really thinking that alan was nuts to 
think he could teach that to beginner
while people able to code stuff I was not able too could miss a so 
obvious point. But I can understand
because not so few people implemented a small reflective kernel. So 
when you do this fun exercise
you cannot get wrong, this is simple, else it does not work.

>> 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).

No because sometimes you want that their object propagate changes. So 
if you create another
subclass of Object you should do the same with Model, else they get 
confused. believe me
they get. because they have to absorb the syntax, the language, the IDE 
and OOP. I think that
this already a lot.

>> 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.

Who did not? That is the point.

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

Yes but this will also ease our life as experts without compromising 
our freedom.

> 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
Yes

> - 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.

Yes

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

Not yet. Just load the code and look for new implementors.
But I'm sure we can do it when I see the snippet that andreas wrote we 
can do everything.
I'm still smashed by the snippet.

Stef

PS: thanks for this email because I was quite sad with the other.

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