Hi. Wait, I do not like this... remember *anything* can be a Morph, not just a

widget (points, "atoms bouncing", etc.).

Could you explain it? Because you can't add point to morph for example. 2016-01-31 12:21 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:

no, I don’t :) I commented there.

On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel@gmail.com> wrote:

Hello

Do you agree?

https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-n...

Cheers, Alex

On 31 Jan 2016, at 12:43, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hi.

Wait, I do not like this... remember *anything* can be a Morph, not just a widget (points, "atoms bouncing", etc.).

Could you explain it? Because you can't add point to morph for example.

A morph can be a point. If you define: Morph new color: Color yellow; extent: 1@1; position: 10@10; openInWorld. you will have a “point” in the world. Now imagine 10k of those (to run simulations or whatever). That’s what I mean :)

2016-01-31 12:21 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: no, I don’t :) I commented there.

...

On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>> wrote:

Hello

Do you agree? https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-n... <https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-n...>

Cheers, Alex

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. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Aliaksei Syrel Sent: Sunday, January 31, 2016 1:17 PM To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default layoutProperties := NullLayoutProperties uniqueInstance to share only one object On Sun, Jan 31, 2016 at 1:06 PM, Esteban Lorenzano <estebanlm@gmail.com<mailto:estebanlm@gmail.com>> wrote: On 31 Jan 2016, at 12:43, Denis Kudriashov <dionisiydk@gmail.com<mailto:dionisiydk@gmail.com>> wrote: Hi. Wait, I do not like this... remember *anything* can be a Morph, not just a widget (points, "atoms bouncing", etc.). Could you explain it? Because you can't add point to morph for example. A morph can be a point. If you define: Morph new color: Color yellow; extent: 1@1; position: 10@10; openInWorld. you will have a “point” in the world. Now imagine 10k of those (to run simulations or whatever). That’s what I mean :) 2016-01-31 12:21 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com<mailto:estebanlm@gmail.com>>: no, I don’t :) I commented there. On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel@gmail.com<mailto:alex.syrel@gmail.com>> wrote: Hello Do you agree? https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-n... Cheers, Alex

On 31 Jan 2016, at 13:38, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

On 31 Jan 2016, at 13:26, Henrik Nergaard <henrik.nergaard@uia.no <mailto:henrik.nergaard@uia.no>> 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.

A good solution is to have share by default and instance-based when needed. For that use a classVariable to instantiate only one NullLayoutProperties use an instance variable that points to it by default one demand change the instance variable to point to a new created instance => you can remove all the ifNil:

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.