There are other conventions like:��

* set...

�� * Delay class >> forMilliseconds: aNumber

^ self new setDelay: aNumber forSemaphore: Semaphore new

* initializeFor...

�� *��DynamicMessageImplementor class>>#for:in:

^ self new initializeFor: aMessage in: aClass

* from:to:...

�� * Bezier2Segment class>>#from:to:via:

^self new from: startPoint to: endPoint via: viaPoint

I dug a bit to produce this script so you can view more yourself...

�� protocols := (Protocol allInstances select: [ :p | p name = 'instance creation' ]) flatCollect: [ :p | p methods ].

�� methods := protocols select: [ :m | (m occurrencesOf: $:) > 1 ].

�� implementors := methods flatCollect: [ :m | m implementors ].

�� constructorExamples := implementors select: [ :i | (i sourceCode includesAll: 'new') or: [ i sourceCode includesAll: 'basicNew' ] ].��

cheers -ben

On Sat, May 2, 2015 at 9:02 PM, Peter Uhn��k <i.uhnak@gmail.com> wrote:

It seems to me that Smalltalkers are not very fond of constructors and I can't comprehend why.

If for example I want to create object X that _needs_ object Y, then I would have to make a Y accessor.

X>>y: anY
�� y := anY

but this makes no sense as I can still change the `y` object at later date breaking everything.

An alternative is having:

X>>initializeWithY: anY
�� y := anY.
�� self initialize.

X>>y: anY
�� ^ self basicNew initalizeWithY: anY.

However I see only 59 initializeWith* methods (in about 6 packages) compared to 2302 initialize methods. Thus I am deducing that doing this is not very common.

Am I missing something or am I trying to unnecessarily constraint the user and I should just trust�� him that he knows what he should use?

As a user of an interface I would prefer not to have useless things available that would just break things.

Thanks,
Peter