Hi All,
Several time I saw the need to add a particular edge between two nodes that I know. I added a new method addEdgeFrom:to: in ViewRenderer. Here the appropriate test. Feel free to comment. -=-=-=-=-=-=-=-=-=-=-=-= testAddEdge | view | view := MOViewRenderer new.
view nodes: (1 to: 2). view addEdgeFrom: 1 to: 2.
window := view open. self assert: (view root edges size = 1). self assert: (view root edges first source = (view nodeForDomainValue: 1)). self assert: (view root edges first target = (view nodeForDomainValue: 2)). -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
Hi Alex,
There is no need for that because you already have support for that:
view := MOViewRenderer new. view nodes: #(1 2). view edge: nil from: 1 to: 2. view open
This is because: Object>>moValue: anArgument ^ self
Cheers, Doru
On 24 Mar 2009, at 16:44, Alexandre Bergel wrote:
Hi All,
Several time I saw the need to add a particular edge between two nodes that I know. I added a new method addEdgeFrom:to: in ViewRenderer. Here the appropriate test. Feel free to comment. -=-=-=-=-=-=-=-=-=-=-=-= testAddEdge | view | view := MOViewRenderer new.
view nodes: (1 to: 2). view addEdgeFrom: 1 to: 2.
window := view open. self assert: (view root edges size = 1). self assert: (view root edges first source = (view nodeForDomainValue: 1)). self assert: (view root edges first target = (view nodeForDomainValue: 2)). -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
I did not see this... It will make addEdgeFrom:to: shorter then.
Thanks, Alexandre
On 24 Mar 2009, at 16:50, Tudor Girba wrote:
Hi Alex,
There is no need for that because you already have support for that:
view := MOViewRenderer new. view nodes: #(1 2). view edge: nil from: 1 to: 2. view open
This is because: Object>>moValue: anArgument ^ self
Cheers, Doru
On 24 Mar 2009, at 16:44, Alexandre Bergel wrote:
Hi All,
Several time I saw the need to add a particular edge between two nodes that I know. I added a new method addEdgeFrom:to: in ViewRenderer. Here the appropriate test. Feel free to comment. -=-=-=-=-=-=-=-=-=-=-=-= testAddEdge | view | view := MOViewRenderer new.
view nodes: (1 to: 2). view addEdgeFrom: 1 to: 2.
window := view open. self assert: (view root edges size = 1). self assert: (view root edges first source = (view nodeForDomainValue: 1)). self assert: (view root edges first target = (view nodeForDomainValue: 2)). -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
But, why would you add another method for this?
Also, please do not add verbs in the API, like (add*). For example, it is edge:from:to:, and not addEdgeFrom:to:.
You might want to name it edgeFrom:to:, but that does not work because the assumption when we do not give the model is to take the collection of the objects behind the nodes.
Like this you can write: view nodes: classes. view edgesFrom: #superclass.
This case is much more often encountered then having an edge without a model at all.
So, all in all, I would not add this new method.
Cheers, Doru
On 24 Mar 2009, at 16:54, Alexandre Bergel wrote:
I did not see this... It will make addEdgeFrom:to: shorter then.
Thanks, Alexandre
On 24 Mar 2009, at 16:50, Tudor Girba wrote:
Hi Alex,
There is no need for that because you already have support for that:
view := MOViewRenderer new. view nodes: #(1 2). view edge: nil from: 1 to: 2. view open
This is because: Object>>moValue: anArgument ^ self
Cheers, Doru
On 24 Mar 2009, at 16:44, Alexandre Bergel wrote:
Hi All,
Several time I saw the need to add a particular edge between two nodes that I know. I added a new method addEdgeFrom:to: in ViewRenderer. Here the appropriate test. Feel free to comment. -=-=-=-=-=-=-=-=-=-=-=-= testAddEdge | view | view := MOViewRenderer new.
view nodes: (1 to: 2). view addEdgeFrom: 1 to: 2.
window := view open. self assert: (view root edges size = 1). self assert: (view root edges first source = (view nodeForDomainValue: 1)). self assert: (view root edges first target = (view nodeForDomainValue: 2)). -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
I see your point. However, I am wondering about limitation of this declarative way of defining nodes and edges. Beside the fact that I had troubles to understand what's really going on when I write "view nodes: ..." and especially "view edges: ...", this syntax misses the inherent imperative way of defining a view with several kinds of nodes and edges. For example, to me, it looks perfectly reasonable to have
-=-=-=-=-=-=-=-=-=-=-=-= view shape: shape1. view nodes: (1 to: 99).
view shape: shape2. view nodes: (100 to 199). -=-=-=-=-=-=-=-=-=-=-=-=
The example is contrived, but it reflect some situation where I need more than one "nodes:" or "edges:" at the same level. A more realistic example may be found in UML, where edges used for simple associations between classes are different from inheritance edges. I will typically add the simple association edges after having done the layout.
I always though that having "addNodes:" and "addEdges:" is more explicit. It seems that Lukas came to the same conclusion (he used "addAll:"). But I might be wrong...
Cheers, Alexandre
On 24 Mar 2009, at 17:19, Tudor Girba wrote:
But, why would you add another method for this?
Also, please do not add verbs in the API, like (add*). For example, it is edge:from:to:, and not addEdgeFrom:to:.
You might want to name it edgeFrom:to:, but that does not work because the assumption when we do not give the model is to take the collection of the objects behind the nodes.
Like this you can write: view nodes: classes. view edgesFrom: #superclass.
This case is much more often encountered then having an edge without a model at all.
So, all in all, I would not add this new method.
Cheers, Doru
On 24 Mar 2009, at 16:54, Alexandre Bergel wrote:
I did not see this... It will make addEdgeFrom:to: shorter then.
Thanks, Alexandre
On 24 Mar 2009, at 16:50, Tudor Girba wrote:
Hi Alex,
There is no need for that because you already have support for that:
view := MOViewRenderer new. view nodes: #(1 2). view edge: nil from: 1 to: 2. view open
This is because: Object>>moValue: anArgument ^ self
Cheers, Doru
On 24 Mar 2009, at 16:44, Alexandre Bergel wrote:
Hi All,
Several time I saw the need to add a particular edge between two nodes that I know. I added a new method addEdgeFrom:to: in ViewRenderer. Here the appropriate test. Feel free to comment. -=-=-=-=-=-=-=-=-=-=-=-= testAddEdge | view | view := MOViewRenderer new.
view nodes: (1 to: 2). view addEdgeFrom: 1 to: 2.
window := view open. self assert: (view root edges size = 1). self assert: (view root edges first source = (view nodeForDomainValue: 1)). self assert: (view root edges first target = (view nodeForDomainValue: 2)). -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Alex,
I am not sure I understand where the limitation is. It's just a naming convention to describe the view, rather than to add things to it. I see no reason to start changing it now.
You can have as many "view nodes: " and "view edges:" you want. For example, the following code, works just fine in Squeak:
view := MOViewRenderer new. view shape: (MORectangleShape new ). view nodes: #(1 2 3 4). view edgeShape: (MOStraightLineShape new). view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1]. view shape: (MORectangleShape new fillColor: Color red). view nodes: #(5 6 7 8). view edgeShape: (MOStraightLineShape new color: Color red). view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1]. view treeLayout. view open
For your case of the layout, you actually want to tell the layout to only take into account the inheritance edges. The solution in is to pass userDefinedEdges: to the layout with the edges returned by the view edges:. For example in the following code I store the second set of edges in an "active" variable and then pass it to the layout:
view := MOViewRenderer new. view shape: (MORectangleShape new ). view nodes: #(1 2 3 4). view edgeShape: (MOStraightLineShape new). view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1]. view shape: (MORectangleShape new fillColor: Color red). view nodes: #(5 6 7 8). view edgeShape: (MOStraightLineShape new color: Color red). active := view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1]. view treeLayout userDefinedEdges: active. view open
Cheers, Doru
On 24 Mar 2009, at 17:47, Alexandre Bergel wrote:
I see your point. However, I am wondering about limitation of this declarative way of defining nodes and edges. Beside the fact that I had troubles to understand what's really going on when I write "view nodes: ..." and especially "view edges: ...", this syntax misses the inherent imperative way of defining a view with several kinds of nodes and edges. For example, to me, it looks perfectly reasonable to have
-=-=-=-=-=-=-=-=-=-=-=-= view shape: shape1. view nodes: (1 to: 99).
view shape: shape2. view nodes: (100 to 199). -=-=-=-=-=-=-=-=-=-=-=-=
The example is contrived, but it reflect some situation where I need more than one "nodes:" or "edges:" at the same level. A more realistic example may be found in UML, where edges used for simple associations between classes are different from inheritance edges. I will typically add the simple association edges after having done the layout.
I always though that having "addNodes:" and "addEdges:" is more explicit. It seems that Lukas came to the same conclusion (he used "addAll:"). But I might be wrong...
Cheers, Alexandre
On 24 Mar 2009, at 17:19, Tudor Girba wrote:
But, why would you add another method for this?
Also, please do not add verbs in the API, like (add*). For example, it is edge:from:to:, and not addEdgeFrom:to:.
You might want to name it edgeFrom:to:, but that does not work because the assumption when we do not give the model is to take the collection of the objects behind the nodes.
Like this you can write: view nodes: classes. view edgesFrom: #superclass.
This case is much more often encountered then having an edge without a model at all.
So, all in all, I would not add this new method.
Cheers, Doru
On 24 Mar 2009, at 16:54, Alexandre Bergel wrote:
I did not see this... It will make addEdgeFrom:to: shorter then.
Thanks, Alexandre
On 24 Mar 2009, at 16:50, Tudor Girba wrote:
Hi Alex,
There is no need for that because you already have support for that:
view := MOViewRenderer new. view nodes: #(1 2). view edge: nil from: 1 to: 2. view open
This is because: Object>>moValue: anArgument ^ self
Cheers, Doru
On 24 Mar 2009, at 16:44, Alexandre Bergel wrote:
Hi All,
Several time I saw the need to add a particular edge between two nodes that I know. I added a new method addEdgeFrom:to: in ViewRenderer. Here the appropriate test. Feel free to comment. -=-=-=-=-=-=-=-=-=-=-=-= testAddEdge | view | view := MOViewRenderer new.
view nodes: (1 to: 2). view addEdgeFrom: 1 to: 2.
window := view open. self assert: (view root edges size = 1). self assert: (view root edges first source = (view nodeForDomainValue: 1)). self assert: (view root edges first target = (view nodeForDomainValue: 2)). -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
I did not suggest that we should change the convention name. There is enough documentation around to make us stick to it. I will rename the method I recently introduced.
Cheers, Alexandre
On 24 Mar 2009, at 21:48, Tudor Girba wrote:
Hi Alex,
I am not sure I understand where the limitation is. It's just a naming convention to describe the view, rather than to add things to it. I see no reason to start changing it now.
You can have as many "view nodes: " and "view edges:" you want. For example, the following code, works just fine in Squeak:
view := MOViewRenderer new. view shape: (MORectangleShape new ). view nodes: #(1 2 3 4). view edgeShape: (MOStraightLineShape new). view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1]. view shape: (MORectangleShape new fillColor: Color red). view nodes: #(5 6 7 8). view edgeShape: (MOStraightLineShape new color: Color red). view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1]. view treeLayout. view open
For your case of the layout, you actually want to tell the layout to only take into account the inheritance edges. The solution in is to pass userDefinedEdges: to the layout with the edges returned by the view edges:. For example in the following code I store the second set of edges in an "active" variable and then pass it to the layout:
view := MOViewRenderer new. view shape: (MORectangleShape new ). view nodes: #(1 2 3 4). view edgeShape: (MOStraightLineShape new). view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1]. view shape: (MORectangleShape new fillColor: Color red). view nodes: #(5 6 7 8). view edgeShape: (MOStraightLineShape new color: Color red). active := view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1]. view treeLayout userDefinedEdges: active. view open
Cheers, Doru
On 24 Mar 2009, at 17:47, Alexandre Bergel wrote:
I see your point. However, I am wondering about limitation of this declarative way of defining nodes and edges. Beside the fact that I had troubles to understand what's really going on when I write "view nodes: ..." and especially "view edges: ...", this syntax misses the inherent imperative way of defining a view with several kinds of nodes and edges. For example, to me, it looks perfectly reasonable to have
-=-=-=-=-=-=-=-=-=-=-=-= view shape: shape1. view nodes: (1 to: 99).
view shape: shape2. view nodes: (100 to 199). -=-=-=-=-=-=-=-=-=-=-=-=
The example is contrived, but it reflect some situation where I need more than one "nodes:" or "edges:" at the same level. A more realistic example may be found in UML, where edges used for simple associations between classes are different from inheritance edges. I will typically add the simple association edges after having done the layout.
I always though that having "addNodes:" and "addEdges:" is more explicit. It seems that Lukas came to the same conclusion (he used "addAll:"). But I might be wrong...
Cheers, Alexandre
On 24 Mar 2009, at 17:19, Tudor Girba wrote:
But, why would you add another method for this?
Also, please do not add verbs in the API, like (add*). For example, it is edge:from:to:, and not addEdgeFrom:to:.
You might want to name it edgeFrom:to:, but that does not work because the assumption when we do not give the model is to take the collection of the objects behind the nodes.
Like this you can write: view nodes: classes. view edgesFrom: #superclass.
This case is much more often encountered then having an edge without a model at all.
So, all in all, I would not add this new method.
Cheers, Doru
On 24 Mar 2009, at 16:54, Alexandre Bergel wrote:
I did not see this... It will make addEdgeFrom:to: shorter then.
Thanks, Alexandre
On 24 Mar 2009, at 16:50, Tudor Girba wrote:
Hi Alex,
There is no need for that because you already have support for that:
view := MOViewRenderer new. view nodes: #(1 2). view edge: nil from: 1 to: 2. view open
This is because: Object>>moValue: anArgument ^ self
Cheers, Doru
On 24 Mar 2009, at 16:44, Alexandre Bergel wrote:
Hi All,
Several time I saw the need to add a particular edge between two nodes that I know. I added a new method addEdgeFrom:to: in ViewRenderer. Here the appropriate test. Feel free to comment. -=-=-=-=-=-=-=-=-=-=-=-= testAddEdge | view | view := MOViewRenderer new.
view nodes: (1 to: 2). view addEdgeFrom: 1 to: 2.
window := view open. self assert: (view root edges size = 1). self assert: (view root edges first source = (view nodeForDomainValue: 1)). self assert: (view root edges first target = (view nodeForDomainValue: 2)). -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Alex,
It seems I managed again to sound like scolding :).
The discussion seemed to me to be more than just the naming convention. So, let me summarize: - do you still need the new method given that you have one that does that already and that by adding the new one we break the conventions for what it means to not pass a model to an edge? - regarding the limitations you mentioned, is the example below enough, or are there more limitations you see? Or did I misunderstood completely?
Again, I do not want to attack, I just want to discuss :).
Cheers, Doru
On 25 Mar 2009, at 10:44, Alexandre Bergel wrote:
I did not suggest that we should change the convention name. There is enough documentation around to make us stick to it. I will rename the method I recently introduced.
Cheers, Alexandre
On 24 Mar 2009, at 21:48, Tudor Girba wrote:
Hi Alex,
I am not sure I understand where the limitation is. It's just a naming convention to describe the view, rather than to add things to it. I see no reason to start changing it now.
You can have as many "view nodes: " and "view edges:" you want. For example, the following code, works just fine in Squeak:
view := MOViewRenderer new. view shape: (MORectangleShape new ). view nodes: #(1 2 3 4). view edgeShape: (MOStraightLineShape new). view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1]. view shape: (MORectangleShape new fillColor: Color red). view nodes: #(5 6 7 8). view edgeShape: (MOStraightLineShape new color: Color red). view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1]. view treeLayout. view open
For your case of the layout, you actually want to tell the layout to only take into account the inheritance edges. The solution in is to pass userDefinedEdges: to the layout with the edges returned by the view edges:. For example in the following code I store the second set of edges in an "active" variable and then pass it to the layout:
view := MOViewRenderer new. view shape: (MORectangleShape new ). view nodes: #(1 2 3 4). view edgeShape: (MOStraightLineShape new). view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1]. view shape: (MORectangleShape new fillColor: Color red). view nodes: #(5 6 7 8). view edgeShape: (MOStraightLineShape new color: Color red). active := view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1]. view treeLayout userDefinedEdges: active. view open
Cheers, Doru
On 24 Mar 2009, at 17:47, Alexandre Bergel wrote:
I see your point. However, I am wondering about limitation of this declarative way of defining nodes and edges. Beside the fact that I had troubles to understand what's really going on when I write "view nodes: ..." and especially "view edges: ...", this syntax misses the inherent imperative way of defining a view with several kinds of nodes and edges. For example, to me, it looks perfectly reasonable to have
-=-=-=-=-=-=-=-=-=-=-=-= view shape: shape1. view nodes: (1 to: 99).
view shape: shape2. view nodes: (100 to 199). -=-=-=-=-=-=-=-=-=-=-=-=
The example is contrived, but it reflect some situation where I need more than one "nodes:" or "edges:" at the same level. A more realistic example may be found in UML, where edges used for simple associations between classes are different from inheritance edges. I will typically add the simple association edges after having done the layout.
I always though that having "addNodes:" and "addEdges:" is more explicit. It seems that Lukas came to the same conclusion (he used "addAll:"). But I might be wrong...
Cheers, Alexandre
On 24 Mar 2009, at 17:19, Tudor Girba wrote:
But, why would you add another method for this?
Also, please do not add verbs in the API, like (add*). For example, it is edge:from:to:, and not addEdgeFrom:to:.
You might want to name it edgeFrom:to:, but that does not work because the assumption when we do not give the model is to take the collection of the objects behind the nodes.
Like this you can write: view nodes: classes. view edgesFrom: #superclass.
This case is much more often encountered then having an edge without a model at all.
So, all in all, I would not add this new method.
Cheers, Doru
On 24 Mar 2009, at 16:54, Alexandre Bergel wrote:
I did not see this... It will make addEdgeFrom:to: shorter then.
Thanks, Alexandre
On 24 Mar 2009, at 16:50, Tudor Girba wrote:
Hi Alex,
There is no need for that because you already have support for that:
view := MOViewRenderer new. view nodes: #(1 2). view edge: nil from: 1 to: 2. view open
This is because: Object>>moValue: anArgument ^ self
Cheers, Doru
On 24 Mar 2009, at 16:44, Alexandre Bergel wrote:
> Hi All, > > Several time I saw the need to add a particular edge between > two nodes that I know. I added a new method addEdgeFrom:to: in > ViewRenderer. > Here the appropriate test. Feel free to comment. > -=-=-=-=-=-=-=-=-=-=-=-= > testAddEdge > | view | > view := MOViewRenderer new. > > view nodes: (1 to: 2). > view addEdgeFrom: 1 to: 2. > > window := view open. > self assert: (view root edges size = 1). > self assert: (view root edges first source = > (view nodeForDomainValue: 1)). > self assert: (view root edges first target = > (view nodeForDomainValue: 2)). > -=-=-=-=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
It seems I managed again to sound like scolding :).
I did not feel so :-) Don't worry :-)
- do you still need the new method given that you have one that does
that already and that by adding the new one we break the conventions for what it means to not pass a model to an edge?
Hard to say right now. Probably not, but I will check with the example of Jannik
- regarding the limitations you mentioned, is the example below
enough, or are there more limitations you see? Or did I misunderstood completely?
I was not aware of this userDefinedEdges:
Cheers, Alexandre
On 25 Mar 2009, at 10:44, Alexandre Bergel wrote:
I did not suggest that we should change the convention name. There is enough documentation around to make us stick to it. I will rename the method I recently introduced.
Cheers, Alexandre
On 24 Mar 2009, at 21:48, Tudor Girba wrote:
Hi Alex,
I am not sure I understand where the limitation is. It's just a naming convention to describe the view, rather than to add things to it. I see no reason to start changing it now.
You can have as many "view nodes: " and "view edges:" you want. For example, the following code, works just fine in Squeak:
view := MOViewRenderer new. view shape: (MORectangleShape new ). view nodes: #(1 2 3 4). view edgeShape: (MOStraightLineShape new). view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1]. view shape: (MORectangleShape new fillColor: Color red). view nodes: #(5 6 7 8). view edgeShape: (MOStraightLineShape new color: Color red). view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1]. view treeLayout. view open
For your case of the layout, you actually want to tell the layout to only take into account the inheritance edges. The solution in is to pass userDefinedEdges: to the layout with the edges returned by the view edges:. For example in the following code I store the second set of edges in an "active" variable and then pass it to the layout:
view := MOViewRenderer new. view shape: (MORectangleShape new ). view nodes: #(1 2 3 4). view edgeShape: (MOStraightLineShape new). view edges: #(1 2 3 4) from: #yourself to: [:x | x + 1]. view shape: (MORectangleShape new fillColor: Color red). view nodes: #(5 6 7 8). view edgeShape: (MOStraightLineShape new color: Color red). active := view edges: #(5 6 7 8) from: #yourself to: [:x | x + 1]. view treeLayout userDefinedEdges: active. view open
Cheers, Doru
On 24 Mar 2009, at 17:47, Alexandre Bergel wrote:
I see your point. However, I am wondering about limitation of this declarative way of defining nodes and edges. Beside the fact that I had troubles to understand what's really going on when I write "view nodes: ..." and especially "view edges: ...", this syntax misses the inherent imperative way of defining a view with several kinds of nodes and edges. For example, to me, it looks perfectly reasonable to have
-=-=-=-=-=-=-=-=-=-=-=-= view shape: shape1. view nodes: (1 to: 99).
view shape: shape2. view nodes: (100 to 199). -=-=-=-=-=-=-=-=-=-=-=-=
The example is contrived, but it reflect some situation where I need more than one "nodes:" or "edges:" at the same level. A more realistic example may be found in UML, where edges used for simple associations between classes are different from inheritance edges. I will typically add the simple association edges after having done the layout.
I always though that having "addNodes:" and "addEdges:" is more explicit. It seems that Lukas came to the same conclusion (he used "addAll:"). But I might be wrong...
Cheers, Alexandre
On 24 Mar 2009, at 17:19, Tudor Girba wrote:
But, why would you add another method for this?
Also, please do not add verbs in the API, like (add*). For example, it is edge:from:to:, and not addEdgeFrom:to:.
You might want to name it edgeFrom:to:, but that does not work because the assumption when we do not give the model is to take the collection of the objects behind the nodes.
Like this you can write: view nodes: classes. view edgesFrom: #superclass.
This case is much more often encountered then having an edge without a model at all.
So, all in all, I would not add this new method.
Cheers, Doru
On 24 Mar 2009, at 16:54, Alexandre Bergel wrote:
I did not see this... It will make addEdgeFrom:to: shorter then.
Thanks, Alexandre
On 24 Mar 2009, at 16:50, Tudor Girba wrote:
> Hi Alex, > > There is no need for that because you already have support for > that: > > view := MOViewRenderer new. > view nodes: #(1 2). > view edge: nil from: 1 to: 2. > view open > > This is because: > Object>>moValue: anArgument > ^ self > > Cheers, > Doru > > > On 24 Mar 2009, at 16:44, Alexandre Bergel wrote: > >> Hi All, >> >> Several time I saw the need to add a particular edge between >> two nodes that I know. I added a new method addEdgeFrom:to: >> in ViewRenderer. >> Here the appropriate test. Feel free to comment. >> -=-=-=-=-=-=-=-=-=-=-=-= >> testAddEdge >> | view | >> view := MOViewRenderer new. >> >> view nodes: (1 to: 2). >> view addEdgeFrom: 1 to: 2. >> >> window := view open. >> self assert: (view root edges size = 1). >> self assert: (view root edges first source = >> (view nodeForDomainValue: 1)). >> self assert: (view root edges first target = >> (view nodeForDomainValue: 2)). >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Tudor Girba