Great work, Simon!
I will try to go over it in more details after Friday.
Just one thing: You forgot to tell us how to load it :)
Cheers,
Doru
On 26 Jan 2011, at 03:11, Alexandre Bergel wrote:
Thanks Simon. This is really cool.
I often got bitten with such queries in the past.
Alexandre
On 25 Jan 2011, at 19:54, Simon Denier wrote:
I believe MooseChef is now 100% functional, with a 95% complete API, and test coverage is
good although not complete (I reused test classes from Moose Cook).
I think that MooseChef should replace the navigation methods provided by MooseCook in
Famix-Extensions
- clean lots of stuff necessary for Moose Cook in Famix-extensions (that's a lot!)
- maybe keep and rewrite a small set of some of the most generic queries of MooseCook
with a MooseChef implementation (like clientClasses) to provide short names?
- merge MooseChef into the Famix-extensions package?
*** Tips and tricks
- no test for queries on accesses right now
- self loops excluded by the scoping operators, should not be? Provide a
#excludeSelfLoops instead
- be aware of the difference between querying a class and querying a package with respect
to class extensions. By definition a class queries all its methods regardless of their
package. A package will only query methods defined in itself, including class extensions
to other packages, but not the one from other packages (that is only for invocations and
accesses)
- there is currently no relation between package and namespace?
MooseChef was conceived with the intent to maximize reuse, exploit polymorphism so that
the implementation is small, easy to browse, understand and debug. It is also quite
verbose with long selectors so that reading the query would minimize all interpretation
error. As a consequence, MooseChef is NOT:
- an optimized library for querying (composing queries create at least one collection at
each step)
- a library with concise meaningful names
What I recommend is to use MooseChef as a specification library:
1) prototype your queries with MooseChef
2) then code an optimized version (without all steps induced by the Chef dataflow, with
cache...), give it a short but meaningful name (like in MooseCook) as a class extension
for your application
3) test your code against the MooseChef specification (you could find bugs in your code,
or in Moose Chef :))
*** Why a replacement for Moose Cook?
Moose Cook was the early effort (principally by Hani) to provide a consistent API for
navigation across multiple subclass of FamixEntity. As a consequence, we figure out a few
choices which are outdated.
- some method names ( *referenced*/*referencing* methods) are confusing as they were
defined in Famix2, implies invocations, while Famix References have now been introduced in
Famix 3 as first class citizens.
- Moose Cook had to define many variants in each impacted class (basically one for each
possible combination of the scope and filter queries above)
- Moose Cook also introduced quite systematically a caching system for all queries
All those points make it quite hard to understand and debug Moose Cook, as they are many
methods, each defined for a specific case, which may or may not called other queries in
cumulative steps. We frequently have to browse through multiple recursive calls in order
to check that a query had the behavior we wanted.
--
Simon Denier
_______________________________________________
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
"Problem solving efficiency grows with the abstractness level of problem
understanding."