On Tue, Jul 19, 2016 at 2:26 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
On Jul 19, 2016, at 5:52 AM, stepharo stepharo@free.fr wrote:
Le 19/7/16 à 11:38, Tudor Girba a écrit :
Hi,
I think we are talking about two different things.
The GT interface is not for people that want to click, but for people that want to program. Not the same audience, and I would certainly not use it for products dedicated to people that do not want to program. We need a better infrastructure for end-user products, and what we have now is not enough. I think that is not a Moose problem, but a Pharo one, and it can only change with Bloc/Brick.
Also, we are talking about the development version of Moose, not the stable one. The development version is not meant to be stable (even if it turns out to be stable enough). For the Moose 5.1/Pharo 4 version, we had a couple of patches that happen after the release, and they got integrated in the respective configurations. I think that shows that we can do that if we really need to.
About a Famix fork: could it be that you are referring to extensions to Famix that are specific to the languages that you are parsing, and not for the common parts? If not, I would love to hear where the issues are and how we can correct them, because I did not see public issues that were not integrated in quite some time.
In any case, I am happy that you are interested in investing in the modeling parts (Fame and Famix). For example, it would be great to have traits deeply used. I would be happy to work with people in any direction. Just make it public and let’s solve real problems.
Ok noted. I was sure you would say that so we will see. This was discussed some years ago on this mailing-list. Check emails of nicolas and anne.
We will send a call for job with a description of tasks we want.
Great.
In a nutshell and from memory
- easier way to describe metamodels (probably based on platypus)
I think it is an interesting goal. I just want to keep as a goal the simplest mapping to the Pharo code, too. Certainly, a separate DSL would be an interesting direction, but another route here would be to have a better tool integration that allows us to map meta-annotations to the code.
-- better handling relationships (union….)
Interesting. Do you have more details?
- probably revisit the bootstrap of FAME because it is really arcane.
- use of slot for inverse FMmultivalue link
Yes.
- using traits at the meta meta level
Yes. And in Famix.
- see how we can integrate better with dynacase toolings
Interesting. Could you detail that use case?
DynaCase is a generic editor : https://dynacase.github.io/ This would be nice if MOOSE and DynaCase are more integrate in the future.