On 8 Nov 2011, at 18:19, Usman Bhatti wrote:
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
It is used only in Moose, and all classes that are used in Moose have a Moose prefix.
- MooseTask and MooseOperator should be in the same package:
Moose-Core since MooseOperator has nothing to do with Smalltalk.
Good point. And we should call it MooseTaskOperator.
- the hierarchy of MooseCompositeImporterTask is really dealing only
with Smalltalk importing logic.
so we should rename it:
SmalltalkCompositeExtractorTask or at least SmalltalkCompositeImporterTaskcolle
Yes, it should be renamed. But, it should have a Moose prefix. This is how we name classes
when we do not have first class namespaces in the language.
- MooseImportClassesTask should be renamed SmalltalkImportClassesTask
since it only create entity extracted from Smalltalk.
It is important to prefix them with Moose.
( 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.
We call importer anything that populates a model from outside data. This is simple.
- Nobody is referencing PackageDescription?
It looks like. I actually do not even know what the class is doing. It probably lingered
around since before using RPackage. I removed it.
- 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
- 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.
I skipped the above part because I do not have enough cycles right now to go into
Doru it would be fun to do some pair programming to address these
changes. Do you have time this evening?
Could be fun, but no time :)
Moose-dev mailing list
"To lead is not to demand things, it is to make them happen."