BlElement copying semantics

[StephanEggermont]

I would expect #copy to be overridden to not copy the parent.

parent := BlElement new.
one := BlElement new
    background: Color random;
    size: 40@40;
    yourself.
parent addChild:one.
two := one copy.
parent addChild: two

[syrel]

Since one of the first versions of Bloc it is forbidden to copy visual elements. Unfortunately, #copy and #deepCopy methods got lost at some point. I restored them with a method comment in #copy that describes that decision :)

Thanks for the reminding! 👍

[dionisiydk]

And how Morphic #dublicate operation will be done in Bloc without copy? (top right halo menu item).

2017-10-04 9:48 GMT+02:00 Aliaksei Syrel notifications@github.com:

Since one of the first versions of Bloc it is forbidden to copy visual elements. Unfortunately, #copy and #deepCopy methods got lost at some point. I restored them with a method comment in #copy that describes that decision :)

Thanks for the reminding! 👍

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pharo-graphics/Bloc/issues/33#issuecomment-334076063, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxaoLkEi2g73PJMMiTvTnBPcUcQ6bOtks5sozhdgaJpZM4PjzHm .

[syrel]

It will not :) We don't see a point in #duplicate for a real world apps. How often do users duplicate UI elements? Supporting copying in all widgets and visualisations is somehow too much for a fancy demo-only feature.

I am looking forward to learn arguments why #duplicate is so important 😉

[syrel]

Talking about halos. We are not sure if they will exist in their current form.

[StephanEggermont]

As a developer, I see use in #duplicate. It provides an excellent direct way of building applications. For end users it definitely makes sense to be able to clone visual representations of actions. I understand that it is difficult to get the context-dependent semantics right

[syrel]

Aha, interesting input, @StephanEggermont 👍 Thanks!

Here is what I wrote as method comment in #copy:

"Visual elements can not be copied.
    The reason for that is unpredictable amount of conflicting copying behaviours.
    For example, what should happen if a copied element is added to the parent?
    Should we create a new element without the parent or add a copied one to the parent of
    the original element? What should we do with View Models? How to deal with event handlers? ...

    Thus, we decided that the most consistent behaviour is to forbid all kind of copying
    and let users instantiate elements by themselves in the way they want it"

The problem with copy is that it is difficult to maintain it... Let's come back to it later when there is nothing else to do 😉

[dionisiydk]

2017-10-04 11:15 GMT+02:00 Aliaksei Syrel notifications@github.com:

It will not :) We don't see a point in #duplicate for a real world apps. How often do users duplicate UI elements? Supporting copying in all widgets and visualisations is somehow to much for a fancy demo-only feature.

I see a lot of fancy demo-only features in Bloc :)

Dublication element like in Morphic is pretty useful for prototyping when you want to see how your app will looks like.

For example in past I usually check how my app will looks with many items at particular panel. So I just copy existing morph element and add it to the panel ("embed into" operation from Halo menu).

Or I played with special appearance where in big list items should be coloured differently depending on some rule. So to check what I want I first create the scene manually with copy/paste existing morphs and then I tune their appearance lively to find good settings. It also allows to check that Idea was good in generally. Then I programmed this "tested" behaviour.

Funny that usually it was done not by me but by my boss who made some design decisions. So it is quite intuitive approach.

And I think JS programmers/designers use this technique a lot to lively play with possible look&feel of the application (but they have very poor tooling for this comparing to morphic).

I am looking forward to learn arguments why #duplicate is so important 😉

So I just want to say that it should not explained as forbidden feature. Let's say that it is just not implemented. And it is not in main priority: general migration to Bloc is not depends on this particular feature.

You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/pharo-graphics/Bloc/issues/33#issuecomment-334097143, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxaoHKVjxOIz2DUUX4hD7ddodA7TKnPks5so0zJgaJpZM4PjzHm .

[dionisiydk]

2017-10-04 11:35 GMT+02:00 Aliaksei Syrel notifications@github.com:

Aha, interesting input, @StephanEggermont https://github.com/stephaneggermont 👍 Thanks!

Here is what I wrote as method comment in #copy:

"Visual elements can not be copied. The reason for that is unpredictable amount of conflicting copying behaviours. For example, what should happen if a copied element is added to the parent? Should we create a new element without the parent or add a copied one to the parent of the original element? What should we do with View Models? How to deal with event handlers? ... Thus, we decided that the most consistent behaviour is to forbid all kind of copying and let users instantiate elements by themselves in the way they want it"

The problem with copy is that it is difficult to maintain it... Let's come back to it later when there is nothing else to do 😉

Does it mean that if I will call #copy on element I will got error?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pharo-graphics/Bloc/issues/33#issuecomment-334101935, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxaoMDKnycJbmlkTFii4Z6t_84TLKZNks5so1FtgaJpZM4PjzHm .

[syrel]

@dionisiydk I see. So the use case is prototyping. Very interesting 🤔 We will need to think if #copy fits there. I like the final goal!

Does it mean that if I will call #copy on element I will got error?

Yes, self shouldNotImplement

[dionisiydk]

2017-10-04 12:57 GMT+02:00 Aliaksei Syrel notifications@github.com:

We will need to think if #copy fits there.

In Morphic it is implemented with #veryDeepCopy. So Morph redefine #copy with it:

Morph>>copy

^self veryDeepCopy.

I like the final goal!

Does it mean that if I will call #copy on element I will got error?

Yes, self shouldNotImplement

I would change it to #shouldBeImplemented. And I hope that primitive method #shallowCopy is continue working. Is it? Because it is always useful to create object from some prototypical instance by copy. Not much logic is required in such cases. And usually not all state is initialised in prototype.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pharo-graphics/Bloc/issues/33#issuecomment-334120232, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxaoNiKKglVannnPVn1jEd2cyRwTCKVks5so2SPgaJpZM4PjzHm .

[dionisiydk]

2017-10-04 11:35 GMT+02:00 Aliaksei Syrel notifications@github.com:

Aha, interesting input, @StephanEggermont https://github.com/stephaneggermont 👍 Thanks!

Here is what I wrote as method comment in #copy:

"Visual elements can not be copied. The reason for that is unpredictable amount of conflicting copying behaviours. For example, what should happen if a copied element is added to the parent? Should we create a new element without the parent or add a copied one to the parent of the original element?

One obvious post condition of copy operation: receiver never modified. Then it leads to other rules according to other invariants of Bloc structure. For example (which I see right now) if you can say that parent of element is always include it in children. Then copied instance should reset own parent.

Interesting to find other rules according this logic.

What should we do with View Models? How to deal with event handlers? ... Thus, we decided that the most consistent behaviour is to forbid all kind of copying and let users instantiate elements by themselves in the way they want it"

The problem with copy is that it is difficult to maintain it... Let's come back to it later when there is nothing else to do 😉

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pharo-graphics/Bloc/issues/33#issuecomment-334101935, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxaoMDKnycJbmlkTFii4Z6t_84TLKZNks5so1FtgaJpZM4PjzHm .

[girba]

Nice conversation!

[girba]

Currently, we see the issue of copying elements as being tightly related to the one of serializing elements. Thus, we will come back to this after we figure out the larger problem. In the meantime, we close the issue.