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
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) MooseOperatorSince 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@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."
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) MooseOperatorSince 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@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."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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) MooseOperatorSince 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@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."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Being happy is a matter of choice."
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) MooseOperatorSince 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@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."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Being happy is a matter of choice."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
Things happen when they happen, not when you talk about them happening.
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 Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
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 Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
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 Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Great.
Doru
On Mon, Nov 14, 2011 at 10:49 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> 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.
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 > Moose-dev@iam.unibe.ch > 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Stéphane Ducasse -
Tudor Girba -
Usman Bhatti