On Thu, Sep 5, 2019 at 3:43 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> IMO, no.
> We don't want to have an empty Matrix by default, it's useless 99% of time.
>

But that's exactly what this commit is about -- having "Matrix new" return
a well-formed (empty) Matrix.  Isn't it what we're talking about?


> So it means initializing twice for nothing 99% of time.
>

"Initializing twice" is something we've accepted as an acceptable trade-off
for nice code since 2006, when we changed Behavior>>#new to call
#initialize.

Via Array empty, we're talking about three measly variable assignments.
Maybe it's just me, but that's light enough to prefer the nicer code.

 - Chris




> That's exactly where I would put basicNew...
>

>

> Le jeu. 5 sept. 2019 à 22:35, Chris Muller <asqueaker at gmail.com> a écrit :
>
>> C'mon guys, it's neither!
>>
>> "Different super call" is a classic smell picked up by Lint, and I agree
>> with Tim about "basicNew" -- is an unnecessary use of a low-level method.
>>
>> So why not simply the same conventional Smalltalky way, overriding
>> #initialize like everywhere else?
>>
>>   initialize
>>        super initialize.
>>        self rows: 0 columns: 0 contents: Array empty
>>
>> And, done..?
>>
>>  - Chris
>>
>> On Wed, Sep 4, 2019 at 3:38 PM tim Rowledge <tim at rowledge.org> wrote:
>>
>>>
>>>
>>> > On 2019-09-04, at 12:58 PM, Thiede, Christoph <
>>> Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>>> >
>>> > Thank you :)
>>> >
>>> > A very minor question: Would you favor [self basicNew] over [super
>>> new]? It will work completely equivalently, but what is the better style?
>>>
>>> ^super new
>>>
>>> `self basicNew` will not always work equivalently. And I can almost
>>> guarantee it will always do the wrong thing just when you feel sure it is
>>> doing the right thing. And you will suffer Debugging Hell.
>>>
>>>
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>> Why use one word when two polysyllabic agglomerates will do?
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190905/56d6a767/attachment.html>