On 1 Feb 2016, at 10:49, Esteban Lorenzano <estebanlm@gmail.com> wrote:

but layoutProperties are not immutable so if you receive an instance of NullLayoutProperties (singleton), and you do something like this:

myMorph cellInset: 5, you has to check for correct properties anyway�� that��s why is implemented as this:

cellInset: aNumber
"Layout specific. This property specifies an extra inset for each cell in the layout."
self assureTableProperties cellInset: aNumber.
self layoutChanged.

I do not think answering a null object here is good�� it will cause infinite problems and you will need to check for correct properties anyway.

That's what I thought might be the problem :-)

So I think the best compromise performance-wise would be that:

Morph>>#layoutProperties returns a new NullLayoutProperties when it currently returns nil.
NullLayoutProperties stores the associated morph as an instance variable
When NullLayoutProperties receives a mutation message

It creates an actual LayoutProperties instance: layoutprops
Forward the mutation message to the layoutprops
morph layoutProperties: layoutprops
self become: layoutprops

Yes, that is rather ugly but it is completely encapsulated, and that's the only way I can see that:

Allow to remove all the nil checks for Morph>>#layoutProperties
Does not break existing code that relies on layoutProperties mutability
Has zero cost when Morph>>#layoutProperties is never used
Has minimal cost when Morph>>#layoutProperties is not mutated: the allocation of a small, transient object that will be reclaimed quickly by the generational GC.

In any case, I would reject such a change (specially at this moment).

I understand that such changes should only be done early in a release cycles.