20 Jun
2011
20 Jun
'11
3:38 p.m.
It might be clearer now.
May be the problem is that what would seem a "normal case" is considered equal
to the "exception" ?
May be an acceptable solution would be to consider "you do not have a natural set of
edges in your entity model" as an exception and make a special method for that
(edges:from:to: with another name), and consider that the normal case is that one does
have entities for the edges?
nicoals
----- Mail original -----
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Lundi 20 Juin 2011 15:28:55
Objet: [Moose-dev] Re: Mondrian question
Hi,
On 20 Jun 2011, at 15:11, Nicolas Anquetil wrote:
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Guys,
For what it is worth, may I suggest that this discussion is going
nowhere?
If each one keeps repeating the same argument this is going to be a
very long argument with nasty side effects (not on the software).
I do not mean to annoy anyone. I actually thought we were actually
making progress (no joke). I think we are all trying to explain what
we think, but I think there is a mismatch in the points of view, and
somehow it just does not seem to come out right :)
I am interested in getting it right, because it can produce a nice
documentation, or it might uncover some other solutions.
Now, may be the problem is that the "input
to Mondrian are not nodes
& edges"?
Because it is based on a graph model and we do use it to represent
graphs, so naturally, one expects to use it that way ...
The next questions are: What does it use as input? And why is it not
just plain edges&nodes?
Because you do not always have a natural set of edges in your entity
model. For example, in Smalltalk, there is no object that represents
inheritance, and yet you would want to represent inheritance as an
edge visually. Visually :). So, to do that, you will take the class as
the model of the edge and draw the edge from that class to the
#superclass.
Now, if you do have an object that represents a relationship, then by
all means use it as the model behind the edge. For example, for the
same example of inheritance, in FAMIX we would use FAMIXInheritance.
In other cases, you have only relations without natural nodes. For
example, if you have a collection of mails that have senders and
receivers as strings, the mail is a relation, but the nodes need to be
constructed.
The idea of Mondrian is to not limit the possibility of visualizing to
only graph models. That is why you have blocks as transformations.
I think, that the answer "The input are only
entities which can be
anything" is not satisfying because users will naturally be thinking
in terms of what they want to see in the end: nodes&edges
How is it now?
nicolas
PS: By the way, the buggy comment is mine, I proposed it when first
trying to understand how things worked. I, also, did not find it
very intuitive that edges: does not simply take a collection of
edges as parameter.
No problem :)
Doru
I am
repeating for the n-th time: The input to Mondrian are not
nodes
& edges. The input are only entities which can be anything. The
engine
simply provides a means to transform your entities into nodes and
edges.
Take this point of view, and you will see that it becomes
consistent
:)
You keep on repeating that you are passing nodes to the edges:, but
you are not. You are always passing some entities from which the
edges
are to be constructed. That is all. It just happens that you choose
to
use the same entity as a model for both an node and an edge. It is
clear that if there is no easy mapping between the entity model and
the graph model, the script can become cumbersome.
Let's take your example:
view node: 'node' forIt: [
view interaction
whenEnteringUpdateNode: [ :aValue |
view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout:
aValue ) ].
view shape rectangle size: 30.
view nodes: (1 to: 9).
view gridLayout gapSize: 10.
First, this example is not instructive because it takes several
shortcuts, but let's just focus on aValue.
In your script, aValue is the value behind the node, not the node.
The
node is another object. Then you use it also as the model for the
edge
because you do not have anything else. So, you will have the same
aValue object used both for creating the node and for creating the
edge.
So, a method like
buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor:
aValuable
is wrong in the context of Mondrian, because it uses the wrong
vocabulary.
How is that? :)
Cheers,
Doru
On 20 Jun 2011, at 14:15, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 20, 2011, at 1:32 PM, Tudor Girba wrote:
> Hi Stef,
>
> On 20 Jun 2011, at 13:18, Stéphane Ducasse wrote:
>
>> I think that this is more than just having correct/good
>> comments....
>>
>> is the parameter passed to edges: consistent? I do not think so
>
> It is consistent. All the time the first argument sent to
> edges:from:to and nodes: is meant to hold a collection of
> entities
> that will be the model behind the graph element. In the case of
> nodes, there is no fancy transformation. In the case of edge,
> there
> are two transformations. That is all.
>
> If you find a case in which this is not true, then we need to fix
> that.
>
>> at least from what I understood
>>
>> edges: from: to:
>> and
>> aView edges: someFamixInvocations from: #sender toAll:
>> #candidates
>>
>> show different cases.
>>
>> Now if nodes: except a collection of entities playing the node
>> role
>> why edges is not a collection of antities playing edges role?
>
> It is.
No it is not
You have to send messages to nodes to get edges so the collection
is
not an edge collection
>> Corollary why in some cases this is the case and in other not?
>
> Just the comments are misleading. It is always the same. Only
> when
> you have something marked differently, you expect a different
> input, like edgesFromAssociations: which expect to have a
> collection of associations. But those are just convenience.
I really lost then.
Because in
view node: 'node' forIt: [
view interaction
whenEnteringUpdateNode: [ :aValue |
view edges: {aValue} from: #yourself toAll: ((1 to: 9)
copyWithout: aValue ) ].
view shape rectangle size: 30.
view nodes: (1 to: 9).
view gridLayout gapSize: 10.
aValue is a node not an Edge?
I always have the problem with mondrian that what I say is wrong.
It
is a wonderful feeling.
Now I see what the API says
is Oh
nodes: nodes you specify nodes with nodes nice
but you specify edges with nodes...... not nice
edges: nodes
And for me this is confusing. Because why do I have to remember
that edges: is not about edges but about nodes that will generate
information about edge.
What you call declarative for me is really confusing.
Now changing aCollection to aCollectionOfEntities only work is
you
explain systematically in the comments that theses are entities
in fact the entities that are not first class relationship and
nodes that can generate information to represent the edges. Else
without context
collectionOfEntities look like collection of objects.
> Again, the comment needs to be fixed.
>
> Does this clarify the situation?
Yes but I do not like it. Why because
edges: from: to: is connoted
Since math exist edges: are edges and not vertices from: is a
vertex
and to: another vertex
So if I need to build visualization in Mondrian I will build a
layer
on top a layer for idiots like me.
buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor:
aValuable
Now I would really like to have a non declarative way of
expressing
that. In fact I do not even understand why a declarative way is
supposed to be better than an imperative one.
Especially because most of the time the order is important in
Mondrian.
Declarations does not talk to me and the the stack semantics of
Mondrian is difficult to understand and debug. And do not dream
there will be no debugger able to debug Mondrian scripts
in the close future. So we are left with method names and
arguments
and guessing right.
What frustrate me with mondrian is that I'm programming in lisp
without any debugger, but worse not printf.....
So I start fast and boum I hit the wall and got trapped in DSL
swamps.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at
them."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev