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.