> On 1 Feb 2016, at 10:49, Esteban Lorenzano <esteba...@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.
