An analysis of the MooseTask hierarchy (third attempt to use gmail crap).

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

An analysis of the MooseTask hierarchy (third attempt to use gmail crap).

Usman Bhatti
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?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: An analysis of the MooseTask hierarchy (third attempt to use gmail crap).

Tudor Girba-2
Hi,

On 8 Nov 2011, at 18:19, Usman Bhatti wrote:

> 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

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  or SmalltalkExtractClassesTask
> 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 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.

I skipped the above part because I do not have enough cycles right now to go into details.

> 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 :)

Doru


> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"To lead is not to demand things, it is to make them happen."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: An analysis of the MooseTask hierarchy (third attempt to use gmail crap).

Stéphane Ducasse

>> ( 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.

Yes I know I gave these names now I think that importing and extracting are two different tasks and
the domain would benefit from this distinction.

>> - 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.
>
> I skipped the above part because I do not have enough cycles right now to go into details.
>
>> 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 :)
>
> Doru
>
>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "To lead is not to demand things, it is to make them happen."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev