Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
Locked
Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
 
|
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
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 > [hidden email] > 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." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
Bcause
>> MooseImportingTask is about Smalltalk only And you want that importers/operators that are not linked to Smalltalk but Java and others also benefit from the error handling and registration of operators. Stef On Nov 9, 2011, at 8:22 AM, Tudor Girba wrote: > 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 >> [hidden email] >> 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." > > > _______________________________________________ > 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 |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
MooseTask is not Smalltalk only. It is an abstract class that is meant to encapsulate one job. If we want multiple jobs at once, we should have a composite task. A simple concept.
Doru On 13 Nov 2011, at 09:03, Stéphane Ducasse wrote: > Bcause >>> MooseImportingTask > is about Smalltalk only > > And you want that importers/operators that are not linked to Smalltalk but Java and others also benefit from > the error handling and registration of operators. > > Stef > > > On Nov 9, 2011, at 8:22 AM, Tudor Girba wrote: > >> 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 >>> [hidden email] >>> 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." >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "Being happy is a matter of choice." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
pfff On Nov 13, 2011, at 9:19 PM, Tudor Girba wrote: > MooseTask is not Smalltalk only. It is an abstract class that is meant to encapsulate one job. If we want multiple jobs at once, we should have a composite task. A simple concept. > > Doru > > > On 13 Nov 2011, at 09:03, Stéphane Ducasse wrote: > >> Bcause >>>> MooseImportingTask >> is about Smalltalk only >> >> And you want that importers/operators that are not linked to Smalltalk but Java and others also benefit from >> the error handling and registration of operators. >> >> Stef >> >> >> On Nov 9, 2011, at 8:22 AM, Tudor Girba wrote: >> >>> 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 >>>> [hidden email] >>>> 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." >>> >>> >>> _______________________________________________ >>> 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 > > -- > www.tudorgirba.com > > "Being happy is a matter of choice." > > > > > _______________________________________________ > 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 |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
In reply to this post by Usman Bhatti
the only composite we have so far is that one and it is only for Smalltalk. I *****KNOW****** that MooseTask is not only for Smalltalk. Believe I read that code. I spent one afternoon on it. Now we can keep it like that too. On Nov 8, 2011, at 7:07 PM, Usman Bhatti wrote: > MooseImportingTask - Renamed SmalltalkImportingTask (add importerClass logic) > MooseCompositeImporterTask > MooseSqueakClassPackageImporterTask -> MoosePharoClassPackageExtractTask > MooseSqueakClasssCategoriesImporterTask - >MoosePharoClassCategoriesExtractTask > MooseImportClassesTask -> MooseExtractClassesTask > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
Hi,
What I meant with my initial comment is that we have to rename the current CompositeTask into something Smalltalk specific and add a real generic CompositeTask. I was simply arguing that having another hook for operators is not the way to go, because tasks should provide this composeability in the first place. Doru On 13 Nov 2011, at 22:03, Stéphane Ducasse wrote: > > > the only composite we have so far is that one and it is only for Smalltalk. > I *****KNOW****** that MooseTask is not only for Smalltalk. > Believe I read that code. > > I spent one afternoon on it. > Now we can keep it like that too. > > > On Nov 8, 2011, at 7:07 PM, Usman Bhatti wrote: > >> MooseImportingTask - Renamed SmalltalkImportingTask (add importerClass logic) >> MooseCompositeImporterTask >> MooseSqueakClassPackageImporterTask -> MoosePharoClassPackageExtractTask >> MooseSqueakClasssCategoriesImporterTask - >MoosePharoClassCategoriesExtractTask >> MooseImportClassesTask -> MooseExtractClassesTask >> > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Things happen when they happen, not when you talk about them happening. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
So ?
because if you read my proposal it was concrete. Then introducing a compositeTask can be ok but it should not be a superclass of MooseCompositeImporterTask because else the logic will be a nightmare What I proposed is to get a MooseTask hierarchy nice and clean and a sub hierarchy only dealing with the extraction of Smalltalk code into SmalltalkExtractingTask > Hi, > > What I meant with my initial comment is that we have to rename the current CompositeTask into something Smalltalk specific and add a real generic CompositeTask. > > I was simply arguing that having another hook for operators is not the way to go, because tasks should provide this composeability in the first place. > > Doru > > > On 13 Nov 2011, at 22:03, Stéphane Ducasse wrote: > >> >> >> the only composite we have so far is that one and it is only for Smalltalk. >> I *****KNOW****** that MooseTask is not only for Smalltalk. >> Believe I read that code. >> >> I spent one afternoon on it. >> Now we can keep it like that too. >> >> >> On Nov 8, 2011, at 7:07 PM, Usman Bhatti wrote: >> >>> MooseImportingTask - Renamed SmalltalkImportingTask (add importerClass logic) >>> MooseCompositeImporterTask >>> MooseSqueakClassPackageImporterTask -> MoosePharoClassPackageExtractTask >>> MooseSqueakClasssCategoriesImporterTask - >MoosePharoClassCategoriesExtractTask >>> MooseImportClassesTask -> MooseExtractClassesTask >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > Things happen when they happen, > not when you talk about them happening. > > > _______________________________________________ > 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 |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
Hi,
On 13 Nov 2011, at 22:21, Stéphane Ducasse wrote: > So ? > > because if you read my proposal it was concrete. > > Then introducing a compositeTask can be ok but it should not be a superclass of MooseCompositeImporterTask > because else the logic will be a nightmare > > What I proposed is to get a MooseTask hierarchy nice and clean > and a sub hierarchy only dealing with the extraction of Smalltalk code into > > SmalltalkExtractingTask This is great. But you also proposed to introduce the plugin mechanism in the Importer class, and I said that we should use a real CompositeTask for this use case. That was all. There was no disagreement on having to refactor the Smalltalk-related tasks. Just about where to add the new plugin mechanism. Cheers, Doru >> Hi, >> >> What I meant with my initial comment is that we have to rename the current CompositeTask into something Smalltalk specific and add a real generic CompositeTask. >> >> I was simply arguing that having another hook for operators is not the way to go, because tasks should provide this composeability in the first place. >> >> Doru >> >> >> On 13 Nov 2011, at 22:03, Stéphane Ducasse wrote: >> >>> >>> >>> the only composite we have so far is that one and it is only for Smalltalk. >>> I *****KNOW****** that MooseTask is not only for Smalltalk. >>> Believe I read that code. >>> >>> I spent one afternoon on it. >>> Now we can keep it like that too. >>> >>> >>> On Nov 8, 2011, at 7:07 PM, Usman Bhatti wrote: >>> >>>> MooseImportingTask - Renamed SmalltalkImportingTask (add importerClass logic) >>>> MooseCompositeImporterTask >>>> MooseSqueakClassPackageImporterTask -> MoosePharoClassPackageExtractTask >>>> MooseSqueakClasssCategoriesImporterTask - >MoosePharoClassCategoriesExtractTask >>>> MooseImportClassesTask -> MooseExtractClassesTask >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> Things happen when they happen, >> not when you talk about them happening. >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "Live like you mean it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
ok
Now how do we proceed? >> because if you read my proposal it was concrete. >> >> Then introducing a compositeTask can be ok but it should not be a superclass of MooseCompositeImporterTask >> because else the logic will be a nightmare >> >> What I proposed is to get a MooseTask hierarchy nice and clean >> and a sub hierarchy only dealing with the extraction of Smalltalk code into >> >> SmalltalkExtractingTask > > This is great. > > But you also proposed to introduce the plugin mechanism in the Importer class, and I said that we should use a real CompositeTask for this use case. That was all. There was no disagreement on having to refactor the Smalltalk-related tasks. Just about where to add the new plugin mechanism. > > Cheers, > Doru > > >>> Hi, >>> >>> What I meant with my initial comment is that we have to rename the current CompositeTask into something Smalltalk specific and add a real generic CompositeTask. >>> >>> I was simply arguing that having another hook for operators is not the way to go, because tasks should provide this composeability in the first place. >>> >>> Doru >>> >>> >>> On 13 Nov 2011, at 22:03, Stéphane Ducasse wrote: >>> >>>> >>>> >>>> the only composite we have so far is that one and it is only for Smalltalk. >>>> I *****KNOW****** that MooseTask is not only for Smalltalk. >>>> Believe I read that code. >>>> >>>> I spent one afternoon on it. >>>> Now we can keep it like that too. >>>> >>>> >>>> On Nov 8, 2011, at 7:07 PM, Usman Bhatti wrote: >>>> >>>>> MooseImportingTask - Renamed SmalltalkImportingTask (add importerClass logic) >>>>> MooseCompositeImporterTask >>>>> MooseSqueakClassPackageImporterTask -> MoosePharoClassPackageExtractTask >>>>> MooseSqueakClasssCategoriesImporterTask - >MoosePharoClassCategoriesExtractTask >>>>> MooseImportClassesTask -> MooseExtractClassesTask >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> Things happen when they happen, >>> not when you talk about them happening. >>> >>> >>> _______________________________________________ >>> 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 > > -- > www.tudorgirba.com > > "Live like you mean it." > > > _______________________________________________ > 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 |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
On 13 Nov 2011, at 23:11, Stéphane Ducasse wrote: > ok > Now how do we proceed? Just go ahead with your proposal of changing the names of the Task hierarchy. Just do not add the plugin mechanism in the importer. Doru >>> because if you read my proposal it was concrete. >>> >>> Then introducing a compositeTask can be ok but it should not be a superclass of MooseCompositeImporterTask >>> because else the logic will be a nightmare >>> >>> What I proposed is to get a MooseTask hierarchy nice and clean >>> and a sub hierarchy only dealing with the extraction of Smalltalk code into >>> >>> SmalltalkExtractingTask >> >> This is great. >> >> But you also proposed to introduce the plugin mechanism in the Importer class, and I said that we should use a real CompositeTask for this use case. That was all. There was no disagreement on having to refactor the Smalltalk-related tasks. Just about where to add the new plugin mechanism. >> >> Cheers, >> Doru >> >> >>>> Hi, >>>> >>>> What I meant with my initial comment is that we have to rename the current CompositeTask into something Smalltalk specific and add a real generic CompositeTask. >>>> >>>> I was simply arguing that having another hook for operators is not the way to go, because tasks should provide this composeability in the first place. >>>> >>>> Doru >>>> >>>> >>>> On 13 Nov 2011, at 22:03, Stéphane Ducasse wrote: >>>> >>>>> >>>>> >>>>> the only composite we have so far is that one and it is only for Smalltalk. >>>>> I *****KNOW****** that MooseTask is not only for Smalltalk. >>>>> Believe I read that code. >>>>> >>>>> I spent one afternoon on it. >>>>> Now we can keep it like that too. >>>>> >>>>> >>>>> On Nov 8, 2011, at 7:07 PM, Usman Bhatti wrote: >>>>> >>>>>> MooseImportingTask - Renamed SmalltalkImportingTask (add importerClass logic) >>>>>> MooseCompositeImporterTask >>>>>> MooseSqueakClassPackageImporterTask -> MoosePharoClassPackageExtractTask >>>>>> MooseSqueakClasssCategoriesImporterTask - >MoosePharoClassCategoriesExtractTask >>>>>> MooseImportClassesTask -> MooseExtractClassesTask >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> Things happen when they happen, >>>> not when you talk about them happening. >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> www.tudorgirba.com >> >> "Live like you mean it." >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "What is more important: To be happy, or to make happy?" _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
>> ok >> Now how do we proceed? > > Just go ahead with your proposal of changing the names of the Task hierarchy. Just do not add the plugin mechanism in the importer. Yes it should be above in the MooseTask Stef > Doru > > >>>> because if you read my proposal it was concrete. >>>> >>>> Then introducing a compositeTask can be ok but it should not be a superclass of MooseCompositeImporterTask >>>> because else the logic will be a nightmare >>>> >>>> What I proposed is to get a MooseTask hierarchy nice and clean >>>> and a sub hierarchy only dealing with the extraction of Smalltalk code into >>>> >>>> SmalltalkExtractingTask >>> >>> This is great. >>> >>> But you also proposed to introduce the plugin mechanism in the Importer class, and I said that we should use a real CompositeTask for this use case. That was all. There was no disagreement on having to refactor the Smalltalk-related tasks. Just about where to add the new plugin mechanism. >>> >>> Cheers, >>> Doru >>> >>> >>>>> Hi, >>>>> >>>>> What I meant with my initial comment is that we have to rename the current CompositeTask into something Smalltalk specific and add a real generic CompositeTask. >>>>> >>>>> I was simply arguing that having another hook for operators is not the way to go, because tasks should provide this composeability in the first place. >>>>> >>>>> Doru >>>>> >>>>> >>>>> On 13 Nov 2011, at 22:03, Stéphane Ducasse wrote: >>>>> >>>>>> >>>>>> >>>>>> the only composite we have so far is that one and it is only for Smalltalk. >>>>>> I *****KNOW****** that MooseTask is not only for Smalltalk. >>>>>> Believe I read that code. >>>>>> >>>>>> I spent one afternoon on it. >>>>>> Now we can keep it like that too. >>>>>> >>>>>> >>>>>> On Nov 8, 2011, at 7:07 PM, Usman Bhatti wrote: >>>>>> >>>>>>> MooseImportingTask - Renamed SmalltalkImportingTask (add importerClass logic) >>>>>>> MooseCompositeImporterTask >>>>>>> MooseSqueakClassPackageImporterTask -> MoosePharoClassPackageExtractTask >>>>>>> MooseSqueakClasssCategoriesImporterTask - >MoosePharoClassCategoriesExtractTask >>>>>>> MooseImportClassesTask -> MooseExtractClassesTask >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> Things happen when they happen, >>>>> not when you talk about them happening. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> -- >>> www.tudorgirba.com >>> >>> "Live like you mean it." >>> >>> >>> _______________________________________________ >>> 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 > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > > > _______________________________________________ > 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 |
Re: Proposal to enhance the MooseTask inheritance and MooseAbstractImporter
|
|
Great.
Doru
On Mon, Nov 14, 2011 at 10:49 AM, Stéphane Ducasse <[hidden email]> wrote:
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |