[squeak-dev] 4.5 -- how should we proceed then?

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Dec 25 00:56:46 UTC 2013


2013/12/24 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>

>
> 2013/12/24 Chris Muller <asqueaker at gmail.com>
>
>> > The other point being whether to invoke new or basicNew is more
>> germane, but
>> > not invoking new is a way to tell my instances are not created like
>> that.
>>
>> It's a way to tell your instances not to initialize _default values_, if
>> any.
>>
>> If a var is added and you add an initialize method, oops.  You better
>> change your constructor too, ha ha...
>>
>> Chris, that's not your best argument, what do you read here?
> ^self basicNew initializeWith: prefix
>                         ^^^^^^^^^
>
> Did you browse HashedCollection>>new: as I suggested?
> It does not send #new, nor #initialize but #initialize:
> This is fairly common in Squeak.
>
>

Not my best answer too, when I re-read it... ;)
Colin has revendicated the right to call self initialize from within
initializeWithXXX: initializer.
You denied this right because that would open the door to arbitrarily
ignore initialize.
But I think you are mistaking here.
Indeed, contrarily to what you said, each initialize SHOULD call another
initialize (*), that is super initialize.
So once we agree that initializeWithXXX is a proper initialize method as
HashedCollection>>initialize: is,
The problem is solved and we can revert to previous version.

(*) except intentionnally in well known cases


>  > We
>> > could push it further and redefine new ^self error as you suggested, but
>> > it's quite heavy...
>>
>> Default values.
>>
>> Nah! We ain't gonna need such mock-ups, or we'll explicitely create some.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131225/87622542/attachment.htm


More information about the Squeak-dev mailing list