> On 31 Jan 2016, at 13:38, Esteban Lorenzano <[email protected]> wrote: > > >> On 31 Jan 2016, at 13:26, Henrik Nergaard <[email protected] >> <mailto:[email protected]>> wrote: >> >> LayoutProperties is an optional part of Morph using some type of defined >> layout (mostly used by the LayoutPolicy subclasses), this is though not the >> only way to do layout for a Morph and its submorphs; so not every morph >> needs it nor should have it. > > exactly :) > > now… I understand this is because a design problem Morphic has since ever: it > fails to differentiate between simple morphs (some kind of “graphical atoms”, > as defined by Stef) and elaborated ones as Widgets… everything coexists > inside a single morph and now we need to pay the price :(
Maybe that can be solved to everyone satisfaction. If layoutProperties could return a NullLayoutProperties instance (this class does not exist yet), then client code would not have to check for nil values, and Morph instances where layoutProperties is never called would suffer no penalty. I do not know if senders of layoutProperties expect to receive a mutable object. If that is the case, some additional cleverness might be needed. Maybe storing a reference to the morph in NullLayoutProperties, and using #become:. Generally, nil tests annoyances should be avoidable using the NullObject pattern.
