John M McIntosh <johnmci at smalltalkconsulting.com> wrote:

> 
> Ok, well this can be a complicated subject. When you create an 
> instance you face the issue of instance creation and how the designer 
> of the class wants you to do it. If he has a "complete instance 
> creation method", usually found in the class instance creation 
> category, then you can use that.
>

That, I understand!

> Doing a new on the class then poking at the instance might also work, 
> but then again it might not correct.
> 
> For a simple example
> 
> thing _ OrderedCollection with: #foo
> 
> versus
> thing _ OrderedCollection new.
> thing add: #foo.
> 
> Both achieve the same results, but as you see they are different.

Yes, this is two ways of doing the same thing...

> A more complex example might be
> thing _ ComplicatedDataBaseConnector useHost: 'database.apple.com'
> 
> If you invoke new against ComplicatedDataBaseConnector it might not 
> do everything you need and you need to invoke other methods against 
> the instance that require more knowledge to arrive at the same state.

Yes, I usually do ComplicatedDataBaseConnector new initialize.  and put
everything
that must be done in the instance method 'initialize'.
As I see it your ComplicatedDataBaseConnector useHost:
'database.apple.com' is a specialized constructor
 
> Also if someone wants to change how the instance creation method 
> useHost: worked, then you could be impacted if you had new and 
> various other methods to achieve the same state. Some classes for 
> example forbid the use of new because of this issue.

OK... so my 'Foo new initialize' is too general in the sense that this
doesn't really tell the programmer what is going on, and if I have to
change something the chances are that I will have to make changes to a
lot of places. 

> 
> new and overriding new.
> 
> You get the warning because you are messing with an issue. Typically 
> you add a new method to your class to do ^super new initialize
> 
> This is to allow the inherited class the ability to run new, then you 
> run your initialization to set anything up that is required. Go take 
> a look at OrderedCollection new: versus new.
> 
> new does
> ^self new: 10
> 
> new: anInteger  does
> ^ super new setCollection: (Array new: anInteger)
> 
> 
> In this case as you see new actually invokes new: which then invokes 
> super new and pokes at itself to set instance variables. One could 
> have had an instance side initalization method aka ^super new 
> initialize: anInteger. to do this instead, but 20 years back it was 
> written the way it was.

 Ok I'm on the road again.

> basicNew
> I seem to recall various folks have written lots of papers on this so 
> I'm not going to attempt much discussion here, but some people feel 
> that at some point in a root class you need to invoke ^super  basicNew
> initialize. to reduce redundant initialization of instance variables. 
> Also there are other reasons for invoking basicNew.
> 
> 
> But back to your question about Point new the correct way, if not for 
> the fact we get an instance of Point by using the @ (technically it's 
> a binary operator @ against a instance of Number which invokes 
> primitive 18) you could either do
> 
> pt _ Point x: 100 y: 200.
> 
> or
> pt _ Point new.
> pt setX: 100 setY : 200
> 
> Both are correct, but one is more elegant.
> 
> Hint try 10 @ 'hello'
> is always interesting to invoke on people, something about what is a 
> language definition, versus usage of the definition.

This last one is surprising...

Thank you John for these explanations.