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