[Moose-dev] Re: An analysis of the MooseTask hierarchy (third attempt to use gmail crap).

( Importer vs extractor I would like to keep the term importer to the action of populating a model and the action to extract model from source code. In java, c3 we have extractor and in Moose importers and extractors) - I would rename SmalltalkImporter as SmalltalkExtractor like that we have a clear line.

- Now our problem is that we would like to run tasks when a a Smalltalk model is extracted and imported and when a mse file is imported. We should probably introduce the logic of the plugin login somewhere in a superclass and (MSEImporter should be a subclass of MooseTask - not verified if make sense) - I have no clue about the contents of the Moose-GenericImporter. It looks like we stopped in the middle of something (which is probably true). - MooseImportingTask is still Smalltalk specific so I would move to the Moose-SmalltalkImporter. - MooseFileStructureImporter looks really broken but it can be a nice example of a subclass of MooseImporterTask (not MooseExtractorTask) - I have no clue about the role of MooseAbstractImportingContext and its relationship with MooseImportingContext. - I would keep MooseImportingContext in generic because it is not only about extracting but about the consistency about models. - MooseAsbtractImporter is a good start but may be it should be a subclass of MooseTask and used as a superclass of MooseFileStructureImporter, MooseImportingTask and (probably MSEReader) and we could add plugin there.

Doru it would be fun to do some pair programming to address these changes. Do you have time this evening?

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev