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

Hi guys here are some notes we wrote when browsing the MooseTask - It would be good to rename MooseTask should be renamed because it has nothing to do in Moose.t - MooseTask and MooseOperator should be in the same package: Moose-Core since MooseOperator has nothing to do with Smalltalk. - the hierarchy of MooseCompositeImporterTask is really dealing only with Smalltalk importing logic. so we should rename it: SmalltalkCompositeExtractorTask or at least SmalltalkCompositeImporterTaskcolle - MooseImportClassesTask should be renamed SmalltalkImportClassesTask or SmalltalkExtractClassesTask since it only create entity extracted from Smalltalk. ( 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. - Nobody is referencing PackageDescription? - 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?