25 Mar
2009
25 Mar
'09
11:13 a.m.
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:
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
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:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev