Spec Experience in Need for Feedback :)
Hi guys I should say that I'm sick (gift from my little boy) so may be this is obvious. I'm looking at the code of Spec and I hate this code :) widgetDo: aBlock ^ self widget ifNotNil: aBlock I do not see why widgetDo: has to test for nil So I transformed widgetDo: aBlock ^ self widget ifNotNil: aBlock into widgetDo: aBlock ^ aBlock cull: self widget BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API. And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more. Stef
2016-02-08 10:37 GMT+01:00 stepharo <stepharo@free.fr>:
Hi guys
I should say that I'm sick (gift from my little boy) so may be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API.
And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call. In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call. (and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).
2016-02-08 11:31 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-02-08 10:37 GMT+01:00 stepharo <stepharo@free.fr>:
Hi guys
I should say that I'm sick (gift from my little boy) so may be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API.
aBlock value: value: value: does not much better than cull:, imho. Usually, the api documentation of the block are just what you'll find in existing code, nothing else.
And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call.
I don't think there is any way around it. You have to decouple view(s) from model(s), and, hence have those propagation constraints by way of notifications. Of course, a true alternative would be to use a proper propagation constraint system...
In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call.
(and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).
In short, whatever way you look at it, this initialization difficulty is a hard problem. Morphic makes it a bit harder than expected because a Morph can be considered as active as soon as it is created, not just when it has been opened in the world. Thierry
2016-02-08 15:02 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:
2016-02-08 11:31 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-02-08 10:37 GMT+01:00 stepharo <stepharo@free.fr>:
Hi guys
I should say that I'm sick (gift from my little boy) so may be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API.
aBlock value: value: value:
does not much better than cull:, imho. Usually, the api documentation of the block are just what you'll find in existing code, nothing else.
And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call.
I don't think there is any way around it. You have to decouple view(s) from model(s), and, hence have those propagation constraints by way of notifications.
Of course, a true alternative would be to use a proper propagation constraint system...
In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call.
(and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).
In short, whatever way you look at it, this initialization difficulty is a hard problem.
Morphic makes it a bit harder than expected because a Morph can be considered as active as soon as it is created, not just when it has been opened in the world.
Here is an example: |t| t:=TextModel new. t text:'hello'. t openWithSpec. t hasUnacceptedEdits it shows that our text has unaccepted edits, although the text did not change. ( and there is actually no text decoration indicating this state). I tried to follow the trace from #openWithSpec to the call that sets #hasUnacceptedEdits:true. I don't think this is a problem of "initialization is difficult" but a problem of pluging rubric text components as widgets for spec. The way spec-models are working and the way rubric works, just don't fit well. (see issue 16873Adding a new Method marks current entry in SendersOf MessageBrowser as dirty for another example. The cause is that rubric somehow changes this "hasUnacceptedEdits state" when the text actually *did not change*. And this again is difficult to trace down. And I don't know how to fix this. Help appreciate
Thierry
Alain is lost somewhere on vacation without internet or something like that :) Le 12/2/16 22:38, Nicolai Hess a écrit :
In short, whatever way you look at it, this initialization difficulty is a hard problem.
Morphic makes it a bit harder than expected because a Morph can be considered as active as soon as it is created, not just when it has been opened in the world.
Here is an example:
|t| t:=TextModel new. t text:'hello'. t openWithSpec. t hasUnacceptedEdits
it shows that our text has unaccepted edits, although the text did not change. ( and there is actually no text decoration indicating this state).
I tried to follow the trace from #openWithSpec to the call that sets #hasUnacceptedEdits:true. I don't think this is a problem of "initialization is difficult" but a problem of pluging rubric text components as widgets for spec. The way spec-models are working and the way rubric works, just don't fit well.
(see issue 16873Adding a new Method marks current entry in SendersOf MessageBrowser as dirty for another example. The cause is that rubric somehow changes this "hasUnacceptedEdits state" when the text actually *did not change*. And this again is difficult to trace down. And I don't know how to fix this.
Help appreciate
Hi nicolai I agree. I will have a look at the Calipso experience of Alain. Because may be Calipso + Spec layout format would be much nicer. Did you look at it? Alain just brainstormed but this is interesting for thinking. Stef What I hate also is that the AbstractApdate>>update: aSymbol self changed: aSymbol This is a bit terrible because the adpater should not exist at runtime and adapter should just encapsulate how to create and set the communication between the model and the view. Now it is in the middle and this is not good. stef Le 8/2/16 11:31, Nicolai Hess a écrit :
2016-02-08 10:37 GMT+01:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi guys
I should say that I'm sick (gift from my little boy) so may be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API.
And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call. In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call.
(and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).
The widget becomes available only once the UI is built, however when you are configuring Spec it is not yet built so it's not available and thus the ugly nil check (well, one of the reasons anyway). This is a big problem with morphic/spec ui elements. You never know for sure
what code this self update ---> search through all (dynamicly added) dependents and notify will finally call.
I don't think there is any way around it. You have to decouple view(s) from model(s), and, hence have those propagation constraints by way of notifications.
About a year ago we were discussing this with Stef and one of the options was to expose all value holders (which has happened in the meantime) and have adapter just connect Spec with Morphic. This is a bit older and needs updating, but I think it still holds somewhat https://gist.github.com/peteruhnak/0fc752d0cea9bde69315 (the idea was to to connect Morphic directly to observe Spec and therefore not have Adapter at all during runtime). Peter On Tue, Feb 9, 2016 at 1:46 PM, stepharo <stepharo@free.fr> wrote:
Hi nicolai
I agree. I will have a look at the Calipso experience of Alain. Because may be Calipso + Spec layout format would be much nicer. Did you look at it? Alain just brainstormed but this is interesting for thinking.
Stef
What I hate also is that the
AbstractApdate>>update: aSymbol
self changed: aSymbol
This is a bit terrible because the adpater should not exist at runtime and adapter should just encapsulate how to create and set the communication between the model and the view. Now it is in the middle and this is not good.
stef
Le 8/2/16 11:31, Nicolai Hess a écrit :
2016-02-08 10:37 GMT+01:00 stepharo <stepharo@free.fr>:
Hi guys
I should say that I'm sick (gift from my little boy) so may be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API.
And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call. In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call.
(and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).
Hi peter :) If I recall, one of the key problem is that the state of certain widgets does not let the adpater do its job nicely and disappear after the bridging. Stef Le 9/2/16 16:31, Peter Uhnák a écrit :
The widget becomes available only once the UI is built, however when you are configuring Spec it is not yet built so it's not available and thus the ugly nil check (well, one of the reasons anyway).
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call.
I don't think there is any way around it. You have to decouple view(s) from model(s), and, hence have those propagation constraints by way of notifications.
About a year ago we were discussing this with Stef and one of the options was to expose all value holders (which has happened in the meantime) and have adapter just connect Spec with Morphic. This is a bit older and needs updating, but I think it still holds somewhat https://gist.github.com/peteruhnak/0fc752d0cea9bde69315 (the idea was to to connect Morphic directly to observe Spec and therefore not have Adapter at all during runtime).
Peter
On Tue, Feb 9, 2016 at 1:46 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi nicolai
I agree. I will have a look at the Calipso experience of Alain. Because may be Calipso + Spec layout format would be much nicer. Did you look at it? Alain just brainstormed but this is interesting for thinking.
Stef
What I hate also is that the
AbstractApdate>>update: aSymbol
self changed: aSymbol
This is a bit terrible because the adpater should not exist at runtime and adapter should just encapsulate how to create and set the communication between the model and the view. Now it is in the middle and this is not good.
stef
Le 8/2/16 11:31, Nicolai Hess a écrit :
2016-02-08 10:37 GMT+01:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi guys
I should say that I'm sick (gift from my little boy) so may be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API.
And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call. In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call.
(and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).
2016-02-09 13:46 GMT+01:00 stepharo <stepharo@free.fr>:
Hi nicolai
I agree. I will have a look at the Calipso experience of Alain. Because may be Calipso + Spec layout format would be much nicer. Did you look at it?
I could not find anything about Calipso, what is it?
Alain just brainstormed but this is interesting for thinking.
Stef
What I hate also is that the
AbstractApdate>>update: aSymbol
self changed: aSymbol
This is a bit terrible because the adpater should not exist at runtime and adapter should just encapsulate how to create and set the communication between the model and the view. Now it is in the middle and this is not good.
stef
Le 8/2/16 11:31, Nicolai Hess a écrit :
2016-02-08 10:37 GMT+01:00 stepharo <stepharo@free.fr>:
Hi guys
I should say that I'm sick (gift from my little boy) so may be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API.
And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call. In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call.
(and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).
2016-02-09 13:46 GMT+01:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi nicolai
I agree. I will have a look at the Calipso experience of Alain. Because may be Calipso + Spec layout format would be much nicer. Did you look at it?
I could not find anything about Calipso, what is it?
http://smalltalkhub.com/#!/~AlainPlantec/Calypso Stef
Alain just brainstormed but this is interesting for thinking.
Stef
What I hate also is that the
AbstractApdate>>update: aSymbol
self changed: aSymbol
This is a bit terrible because the adpater should not exist at runtime and adapter should just encapsulate how to create and set the communication between the model and the view. Now it is in the middle and this is not good.
stef
Le 8/2/16 11:31, Nicolai Hess a écrit :
2016-02-08 10:37 GMT+01:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi guys
I should say that I'm sick (gift from my little boy) so may be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API.
And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call. In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call.
(and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).
2016-02-13 16:24 GMT+01:00 stepharo <stepharo@free.fr>:
2016-02-09 13:46 GMT+01:00 stepharo <stepharo@free.fr>:
Hi nicolai
I agree. I will have a look at the Calipso experience of Alain. Because may be Calipso + Spec layout format would be much nicer. Did you look at it?
I could not find anything about Calipso, what is it?
Sorry still can not find out what this is about. With this amount of documentation, I guess it is not yet ready for review/feedback.
Stef
Alain just brainstormed but this is interesting for thinking.
Stef
What I hate also is that the
AbstractApdate>>update: aSymbol
self changed: aSymbol
This is a bit terrible because the adpater should not exist at runtime and adapter should just encapsulate how to create and set the communication between the model and the view. Now it is in the middle and this is not good.
stef
Le 8/2/16 11:31, Nicolai Hess a écrit :
2016-02-08 10:37 GMT+01:00 stepharo < <stepharo@free.fr>stepharo@free.fr> :
Hi guys
I should say that I'm sick (gift from my little boy) so may be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API.
And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never know for sure what code this self update ---> search through all (dynamicly added) dependents and notify will finally call. In this example we are about to *built* the widgets and in this run , we change a component that will update all dependents goes back and forth between model, adapter and widget. And all before the widget is actually accessible for the widgetDo: call.
(and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).
participants (4)
-
Nicolai Hess -
Peter Uhnák -
stepharo -
Thierry Goubier