The Trunk: Collections-mt.851.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Collections-mt.851.mcz

commits-2
Marcel Taeumel uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-mt.851.mcz

==================== Summary ====================

Name: Collections-mt.851
Author: mt
Time: 2 September 2019, 11:43:25.156478 am
UUID: f2b64324-98fe-5846-8e48-cfc0a1481b61
Ancestors: Collections-ct.850

Merges Collections-ct.829, which I moved to treated inbox due to incompatible ancestry.

"Refactor Matrix instance creation: Matrix new returns a valid (empty) matrix instead of an uninitialized object"

=============== Diff against Collections-ct.850 ===============

Item was added:
+ ----- Method: Matrix class>>new (in category 'instance creation') -----
+ new
+ ^self rows: 0 columns: 0!

Item was changed:
  ----- Method: Matrix class>>rows:columns:contents: (in category 'private') -----
  rows: rows columns: columns contents: contents
+ ^super new rows: rows columns: columns contents: contents!
- ^self new rows: rows columns: columns contents: contents!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Christoph Thiede

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?


Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
Gesendet: Montag, 2. September 2019 11:43:30
An: [hidden email]; [hidden email]
Betreff: [squeak-dev] The Trunk: Collections-mt.851.mcz
 
Marcel Taeumel uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-mt.851.mcz

==================== Summary ====================

Name: Collections-mt.851
Author: mt
Time: 2 September 2019, 11:43:25.156478 am
UUID: f2b64324-98fe-5846-8e48-cfc0a1481b61
Ancestors: Collections-ct.850

Merges Collections-ct.829, which I moved to treated inbox due to incompatible ancestry.

"Refactor Matrix instance creation: Matrix new returns a valid (empty) matrix instead of an uninitialized object"

=============== Diff against Collections-ct.850 ===============

Item was added:
+ ----- Method: Matrix class>>new (in category 'instance creation') -----
+ new
+        ^self rows: 0 columns: 0!

Item was changed:
  ----- Method: Matrix class>>rows:columns:contents: (in category 'private') -----
  rows: rows columns: columns contents: contents
+        ^super new rows: rows columns: columns contents: contents!
-        ^self new rows: rows columns: columns contents: contents!




Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

timrowledge


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Nicolas Cellier
Hmm, I just starred at method 'source with it' in a SpurVMMaker image and got
- 252 hits for 'self basicNew';
- 109 hits for 'super new'.

So it might depend on context... This would deserve more statistics (age of method, initials, whether new is raising an Error or not, whether instance side initialize does nothing or the wrong thing, etc...)

Le mer. 4 sept. 2019 à 22:38, tim Rowledge <[hidden email]> a écrit :


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?







cbc
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

cbc
Non-scientific sampling, there are many places where new sends basicNew initialize, so the sender either wasn't aware new already did that, or didn't trust Behaviour>>new to keep doing that.  Those can obviously just be fixed if desired.  (Monticello code seems rife with this, interestingly).

One specifically called out "Superclasses might [do something wrong]" to justify calling #basicNew in #new.  Many callers are class side methods that intentionally setup the variables in subsequent calls to the instance created by #basicNew, such as DateAndTime.

So, a mishmash of reasons.

-cbc

On Wed, Sep 4, 2019 at 2:08 PM Nicolas Cellier <[hidden email]> wrote:
Hmm, I just starred at method 'source with it' in a SpurVMMaker image and got
- 252 hits for 'self basicNew';
- 109 hits for 'super new'.

So it might depend on context... This would deserve more statistics (age of method, initials, whether new is raising an Error or not, whether instance side initialize does nothing or the wrong thing, etc...)

Le mer. 4 sept. 2019 à 22:38, tim Rowledge <[hidden email]> a écrit :


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?








Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

timrowledge
In reply to this post by Nicolas Cellier
Well, to try to explain this mostly to Christoph, #basicNew should do only the primitive creation of the chunk of object memory, hence the 'basic' (and that does include some hacks for certain classes likeBoxedFloat etc).
#new and other initial creation methods can do further things, like setting initial values of some instance variables, registering external resources, etc.

So they do not in general work equivalently, deliberately. At the most basic level, #new sends #basicNew to create the memory and then #initialize to do the ... initialisation. If that initialize does stuff your specific needs would prefer to avoid, use #basicNew and your own initialisation sequence.

As an example, consider WriteStream>on:from:to: which uses `self basicNew`. It could use #new without any difference in effect because there is no implementation of #initialize for WriteStreams until you get to the null version in ProtoObject.

In contrast, imagine a class where the normal use needs a load of instance variable to be set up just so, but you have a need for a quite different setup and it would waste a lot of cycles to do the typical init and then overwrite almost all of it. That might justify a separate creation method that uses #basicNew and a specialised init method.

There's also the question of self vs super in your original question. Remember, super is for case where you need to skip up the class tree starting in the superclass of *the class in which the method you are running* lives. This is *not* always the super class of the object executing the method. Lots of people get this wrong.

There are good explanations of the real effects of this crucial point in the Blue Book etc and you really need an example class tree with at least 4 level and it's too long to type here. Suffice to say that the practical difference between `self basicNew` and `super new` can be significant.

> On 2019-09-04, at 2:07 PM, Nicolas Cellier <[hidden email]> wrote:
>
> Hmm, I just starred at method 'source with it' in a SpurVMMaker image and got
> - 252 hits for 'self basicNew';
> - 109 hits for 'super new'.
>
> So it might depend on context... This would deserve more statistics (age of method, initials, whether new is raising an Error or not, whether instance side initialize does nothing or the wrong thing, etc...)
>
> Le mer. 4 sept. 2019 à 22:38, tim Rowledge <[hidden email]> a écrit :
>
>
> > On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Why use one word when two polysyllabic agglomerates will do?
>
>
>
>
>
>


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computing Dictionary: LOOP: (go to LOOP)



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Nicolas Cellier
In reply to this post by cbc
The funny thing is that the object class (a Metaclass) is yet another object than the new instance.
It thus has absolutely no other way to control the construction of this new instance, than to kindly ask the instance by sending a message initialize.
Even if it may sound more imperative like object setThisTo: 1 andThatTo: Array new, only the instance knows how it will do it (or just fake).
Somehow the instance is thrown away un-initialized in the world, and we try to repair ASAP. I wonder how Newspeak resolved this.

Systematic send of initialize in Behavior was a relatively late decision (not in Smalltalk-80), that's why I was speaking of method age: self basicNew initialize was the old way to do it indeed, left at discretion of classes when there were no generic initialize method in Object (ProtoObject).

We can agree that super new is the canonical way to instantiate when additional behavior is required, with exceptions when super new or self initialize won't do the right thing. And instance side initialize should better super initialize too, generally.

Le mer. 4 sept. 2019 à 23:58, Chris Cunningham <[hidden email]> a écrit :
Non-scientific sampling, there are many places where new sends basicNew initialize, so the sender either wasn't aware new already did that, or didn't trust Behaviour>>new to keep doing that.  Those can obviously just be fixed if desired.  (Monticello code seems rife with this, interestingly).

One specifically called out "Superclasses might [do something wrong]" to justify calling #basicNew in #new.  Many callers are class side methods that intentionally setup the variables in subsequent calls to the instance created by #basicNew, such as DateAndTime.

So, a mishmash of reasons.

-cbc

On Wed, Sep 4, 2019 at 2:08 PM Nicolas Cellier <[hidden email]> wrote:
Hmm, I just starred at method 'source with it' in a SpurVMMaker image and got
- 252 hits for 'self basicNew';
- 109 hits for 'super new'.

So it might depend on context... This would deserve more statistics (age of method, initials, whether new is raising an Error or not, whether instance side initialize does nothing or the wrong thing, etc...)

Le mer. 4 sept. 2019 à 22:38, tim Rowledge <[hidden email]> a écrit :


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?









Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Christoph Thiede
In reply to this post by timrowledge

Okay, thank you for the really comprehensive clarification :)


I was already aware of the "basic" meaning of #basicNew, but I also met a pattern that told me to only use super to call the same-named base method. It feels like breaking with the law of encapsulation when you can always refer to the base version of a method that has been explicitly changed in the current class.


But I guess in this case, it is more important to deal with possible logic that could be introduced in (Proto)Object>>#initialize.


Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
Gesendet: Mittwoch, 4. September 2019 23:43:22
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Trunk: Collections-mt.851.mcz
 
Well, to try to explain this mostly to Christoph, #basicNew should do only the primitive creation of the chunk of object memory, hence the 'basic' (and that does include some hacks for certain classes likeBoxedFloat etc).
#new and other initial creation methods can do further things, like setting initial values of some instance variables, registering external resources, etc.

So they do not in general work equivalently, deliberately. At the most basic level, #new sends #basicNew to create the memory and then #initialize to do the ... initialisation. If that initialize does stuff your specific needs would prefer to avoid, use #basicNew and your own initialisation sequence.

As an example, consider WriteStream>on:from:to: which uses `self basicNew`. It could use #new without any difference in effect because there is no implementation of #initialize for WriteStreams until you get to the null version in ProtoObject.

In contrast, imagine a class where the normal use needs a load of instance variable to be set up just so, but you have a need for a quite different setup and it would waste a lot of cycles to do the typical init and then overwrite almost all of it. That might justify a separate creation method that uses #basicNew and a specialised init method.

There's also the question of self vs super in your original question. Remember, super is for case where you need to skip up the class tree starting in the superclass of *the class in which the method you are running* lives. This is *not* always the super class of the object executing the method. Lots of people get this wrong.

There are good explanations of the real effects of this crucial point in the Blue Book etc and you really need an example class tree with at least 4 level and it's too long to type here. Suffice to say that the practical difference between `self basicNew` and `super new` can be significant.

> On 2019-09-04, at 2:07 PM, Nicolas Cellier <[hidden email]> wrote:
>
> Hmm, I just starred at method 'source with it' in a SpurVMMaker image and got
> - 252 hits for 'self basicNew';
> - 109 hits for 'super new'.
>
> So it might depend on context... This would deserve more statistics (age of method, initials, whether new is raising an Error or not, whether instance side initialize does nothing or the wrong thing, etc...)
>
> Le mer. 4 sept. 2019 à 22:38, tim Rowledge <[hidden email]> a écrit :
>
>
> > On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Why use one word when two polysyllabic agglomerates will do?
>
>
>
>
>
>


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computing Dictionary: LOOP: (go to LOOP)





Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Nicolas Cellier
To be absolutely thorough, also consider how the new: message is associated to basicNew:  or super new: and initialize: for variable subclasses - or eventually just initialize: for those quaking like a variable subclass...

Le jeu. 5 sept. 2019 à 00:27, Thiede, Christoph <[hidden email]> a écrit :

Okay, thank you for the really comprehensive clarification :)


I was already aware of the "basic" meaning of #basicNew, but I also met a pattern that told me to only use super to call the same-named base method. It feels like breaking with the law of encapsulation when you can always refer to the base version of a method that has been explicitly changed in the current class.


But I guess in this case, it is more important to deal with possible logic that could be introduced in (Proto)Object>>#initialize.


Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
Gesendet: Mittwoch, 4. September 2019 23:43:22
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Trunk: Collections-mt.851.mcz
 
Well, to try to explain this mostly to Christoph, #basicNew should do only the primitive creation of the chunk of object memory, hence the 'basic' (and that does include some hacks for certain classes likeBoxedFloat etc).
#new and other initial creation methods can do further things, like setting initial values of some instance variables, registering external resources, etc.

So they do not in general work equivalently, deliberately. At the most basic level, #new sends #basicNew to create the memory and then #initialize to do the ... initialisation. If that initialize does stuff your specific needs would prefer to avoid, use #basicNew and your own initialisation sequence.

As an example, consider WriteStream>on:from:to: which uses `self basicNew`. It could use #new without any difference in effect because there is no implementation of #initialize for WriteStreams until you get to the null version in ProtoObject.

In contrast, imagine a class where the normal use needs a load of instance variable to be set up just so, but you have a need for a quite different setup and it would waste a lot of cycles to do the typical init and then overwrite almost all of it. That might justify a separate creation method that uses #basicNew and a specialised init method.

There's also the question of self vs super in your original question. Remember, super is for case where you need to skip up the class tree starting in the superclass of *the class in which the method you are running* lives. This is *not* always the super class of the object executing the method. Lots of people get this wrong.

There are good explanations of the real effects of this crucial point in the Blue Book etc and you really need an example class tree with at least 4 level and it's too long to type here. Suffice to say that the practical difference between `self basicNew` and `super new` can be significant.

> On 2019-09-04, at 2:07 PM, Nicolas Cellier <[hidden email]> wrote:
>
> Hmm, I just starred at method 'source with it' in a SpurVMMaker image and got
> - 252 hits for 'self basicNew';
> - 109 hits for 'super new'.
>
> So it might depend on context... This would deserve more statistics (age of method, initials, whether new is raising an Error or not, whether instance side initialize does nothing or the wrong thing, etc...)
>
> Le mer. 4 sept. 2019 à 22:38, tim Rowledge <[hidden email]> a écrit :
>
>
> > On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Why use one word when two polysyllabic agglomerates will do?
>
>
>
>
>
>


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computing Dictionary: LOOP: (go to LOOP)






Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Nicolas Cellier
Hmm, got it wrong, it should read (basicNew: AND initialize:) OR super new:

Le jeu. 5 sept. 2019 à 00:40, Nicolas Cellier <[hidden email]> a écrit :
To be absolutely thorough, also consider how the new: message is associated to basicNew:  or super new: and initialize: for variable subclasses - or eventually just initialize: for those quaking like a variable subclass...

Le jeu. 5 sept. 2019 à 00:27, Thiede, Christoph <[hidden email]> a écrit :

Okay, thank you for the really comprehensive clarification :)


I was already aware of the "basic" meaning of #basicNew, but I also met a pattern that told me to only use super to call the same-named base method. It feels like breaking with the law of encapsulation when you can always refer to the base version of a method that has been explicitly changed in the current class.


But I guess in this case, it is more important to deal with possible logic that could be introduced in (Proto)Object>>#initialize.


Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
Gesendet: Mittwoch, 4. September 2019 23:43:22
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Trunk: Collections-mt.851.mcz
 
Well, to try to explain this mostly to Christoph, #basicNew should do only the primitive creation of the chunk of object memory, hence the 'basic' (and that does include some hacks for certain classes likeBoxedFloat etc).
#new and other initial creation methods can do further things, like setting initial values of some instance variables, registering external resources, etc.

So they do not in general work equivalently, deliberately. At the most basic level, #new sends #basicNew to create the memory and then #initialize to do the ... initialisation. If that initialize does stuff your specific needs would prefer to avoid, use #basicNew and your own initialisation sequence.

As an example, consider WriteStream>on:from:to: which uses `self basicNew`. It could use #new without any difference in effect because there is no implementation of #initialize for WriteStreams until you get to the null version in ProtoObject.

In contrast, imagine a class where the normal use needs a load of instance variable to be set up just so, but you have a need for a quite different setup and it would waste a lot of cycles to do the typical init and then overwrite almost all of it. That might justify a separate creation method that uses #basicNew and a specialised init method.

There's also the question of self vs super in your original question. Remember, super is for case where you need to skip up the class tree starting in the superclass of *the class in which the method you are running* lives. This is *not* always the super class of the object executing the method. Lots of people get this wrong.

There are good explanations of the real effects of this crucial point in the Blue Book etc and you really need an example class tree with at least 4 level and it's too long to type here. Suffice to say that the practical difference between `self basicNew` and `super new` can be significant.

> On 2019-09-04, at 2:07 PM, Nicolas Cellier <[hidden email]> wrote:
>
> Hmm, I just starred at method 'source with it' in a SpurVMMaker image and got
> - 252 hits for 'self basicNew';
> - 109 hits for 'super new'.
>
> So it might depend on context... This would deserve more statistics (age of method, initials, whether new is raising an Error or not, whether instance side initialize does nothing or the wrong thing, etc...)
>
> Le mer. 4 sept. 2019 à 22:38, tim Rowledge <[hidden email]> a écrit :
>
>
> > On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Why use one word when two polysyllabic agglomerates will do?
>
>
>
>
>
>


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computing Dictionary: LOOP: (go to LOOP)






Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Chris Muller-3
In reply to this post by timrowledge
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 <[hidden email]> wrote:


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?







Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Nicolas Cellier
IMO, no.
We don't want to have an empty Matrix by default, it's useless 99% of time.
So it means initializing twice for nothing 99% of time.
That's exactly where I would put basicNew...

Le jeu. 5 sept. 2019 à 22:35, Chris Muller <[hidden email]> 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 <[hidden email]> wrote:


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?








Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Chris Muller-3
On Thu, Sep 5, 2019 at 3:43 PM Nicolas Cellier <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?









Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Nicolas Cellier


Le jeu. 5 sept. 2019 à 23:52, Chris Muller <[hidden email]> a écrit :
On Thu, Sep 5, 2019 at 3:43 PM Nicolas Cellier <[hidden email]> 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?
 
Yes, but the 1% of case when this could be useful should not spoil the 99%.

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.  

The reason to put initialize in Behavior was to avoid hundreds of duplications of ^self basicNew initialize
The trade off was to eventually call an empty initialize method for those not needing one

Most classes take care to not double initialize when using alternate instance creation method.
That's why they use basicNew/basicNew:.
So we can have our cake and eat it too.

Wasting does not fit the predominant definition of nice nowadays, at least not mine ;)

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 <[hidden email]> 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 <[hidden email]> wrote:


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?










Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

Chris Muller-3
In reply to this post by Chris Muller-3

Via Array empty, we're talking about three measly variable assignments. 

I just remembered your prior argument against using Array empty instead of creating one so, okay, an allocation would push it over the line.

I can understand wanting extreme efficiency for very abstract classes like Point and Rectangle, so maybe Matrix is one of those.

Best,
  Chris
 
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 <[hidden email]> 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 <[hidden email]> wrote:


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?









Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-mt.851.mcz

marcel.taeumel
In reply to this post by Chris Muller-3
Hi Chris. :-)

"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.  

Hmm... disagree. Slightly. I like that #new calls #initialize. Yet, it can always be a smell that can be corrected via "super new" or "self basicNew myCustomInitialize". There are several examples in the image of custom initializers that get called explicitely after #basicNew. Though, I prefer the #basicNew+#myCustomInitialize over "super new".

Best,
Marcel

Am 05.09.2019 23:52:39 schrieb Chris Muller <[hidden email]>:

On Thu, Sep 5, 2019 at 3:43 PM Nicolas Cellier <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


> On 2019-09-04, at 12:58 PM, Thiede, Christoph <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?