On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard@uia.no> wrote:

>Purpose of that catch, as mentioned by Nicolai, is indeed to ignore late initialized objects. For example, imagine a Morph with height that is equal to >owner's height. In this case one would write in #initialize:

>Initialize

>�� self height: [ :morph | morph owner height ].

No.

ownerChanged

self height: owner height.

��..

One should not rely on the owner being set during initialization (90% of the time at least), it makes morphs too reliant on certain cases, which makes them harder to use/understand.

If the morph must have an owner to operate properly, it loses many of its abilities such as being its own root, for example to make images.

ThatMorph new exportAsPng.

��

Amen. Simply avoid using objects in incomplete state to prevent errors like we see in this topic. That means, you should not mess with object's properties until it is fully initialized, that's what #initialize for.
If you have coupling and chicken and egg problem like parent/child relationship - you shall again make sure nobody accessing that couple from outside while it is still in inconsistent state, and then once it is fully initialized - you don't need to guard against silly nil errors, because everything is set up.
And in that couple, you can split things on stages, making sure that on initial stage, you again don't use/access not yet initialized properties.

You need a plan, to be able to not put cart in front of the horse and that is much better than putting it that way and then trying to deal with it in a way like on-do-nothing pattern.��

Once again, one way or another - you don't need to use on-do-nothing, if you doing things right. And if you need it - then that indicates that you got a problem, and instead of solving and fixing it, you bury it under "catch-all and shut-up" gravestone :)

��

Best regards,

Henrik

Best regards,
Igor Stasenko.