MooseChef 4/4, migration, tips and tricks

>
> 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev