9 Nov
2011
9 Nov
'11
8:22 a.m.
Hi,
Why add the mechanism in the MooseAbstractImporter when we can simply use a composite
task?
Do you have a particular use case that cannot be solved with tasks?
Cheers,
Doru
On 8 Nov 2011, at 19:07, Usman Bhatti wrote:
Here is a proposal
MooseTask
MooseAbstractImporter (which right now is not used and only contain error
handling and importingContext)
this class could hold the plugin mechanism that would be run
as a tearDown from now.
MooseImportingTask - Renamed SmalltalkImportingTask (add importerClass
logic)
MooseCompositeImporterTask
MooseSqueakClassPackageImporterTask ->
MoosePharoClassPackageExtractTask
MooseSqueakClasssCategoriesImporterTask -
>MoosePharoClassCategoriesExtractTask
MooseImportClassesTask -> MooseExtractClassesTask
FileStructureImporter(/Extractor)
MooseOperator
Since we will not be able to inherit from the same superclass MSEReader and
MooseAbstractImporter.
We could define one trait to represent the plugin management and apply to the MSEReader
and MooseAbstractImporter.
So let us know what you think.
Stef and Usman
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."