Hi,
by accident, I saw this discussion.
(20:07:51) mbriskar: lincolnthree: but if you plan to have
classification in one rule and it's decorators in the another rules,
there is no other way then to save it in the graph
(20:07:57) LincolnBaxter: mbriskar: meta-model == windup's java
in-memory representation of the project…. look at the code
(20:08:35) LincolnBaxter: mbriskar: why would classifications and
decorators be in separate rules?
(20:08:42) mbriskar: *lincolnthree, jsightler, ozizka: sorry but I just
feel all of you have a different thinking of how to migrate that makes
me confused as ...*
(20:08:57) mbriskar: never
(20:09:15) mbriskar: lincolnthree: that's what Ondra thinks
(20:13:33) LincolnBaxter: mbriskar: i don't think they should be in
separate rules either
So, why should it be in separate rules?
Not sure if you (whoever) have really seen what those classification and
decorator does.
Probably you think it compares to WHEN and PERFORM. It does not.
At least not always.
I'll gladly remind what was decided on the F2F (correct me if I
misunderstood) :
We will store the intermediate information into the graph, making the
rules decoupled.
E.g. we will go through the files, using rules, and examine what they are.
Then, with another rules, we will query the graph and process the files
in some other way.
In other words, we already do classify using some rules, and decorate
using others.
The limitation of the legacy Windup rules is that they are a tree. The
context of one classifier is lost after it's processed.
If you want to do the same operation in other classifier, you have to
copy it.
For example: If you classify FooBar XML file A) by namespace
http://foo.com/bar B) by finding an /foo-bar element in it, then
whatever you do with them has to be coded twice.
We do not want to mimick this limitation. Therefore, we want one rule
for A, other rule for B, and third rule for whatever is done with them next.
Regards, Ondra