8 Nov
2011
8 Nov
'11
7:07 p.m.
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
9 Nov
9 Nov
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."
13 Nov
13 Nov
9:03 a.m.
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
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."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:19 p.m.
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
--
www.tudorgirba.com
"Being happy is a matter of choice."
> 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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:01 p.m.
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
--
www.tudorgirba.com
"Being happy is a matter of choice."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev > 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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:03 p.m.
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
10:12 p.m.
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:
--
www.tudorgirba.com
Things happen when they happen,
not when you talk about them happening.
MooseImportingTask - Renamed
SmalltalkImportingTask (add importerClass logic)
MooseCompositeImporterTask
MooseSqueakClassPackageImporterTask ->
MoosePharoClassPackageExtractTask
MooseSqueakClasssCategoriesImporterTask -
>MoosePharoClassCategoriesExtractTask
MooseImportClassesTask -> MooseExtractClassesTask
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:21 p.m.
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:
--
www.tudorgirba.com
Things happen when they happen,
not when you talk about them happening.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev MooseImportingTask - Renamed
SmalltalkImportingTask (add importerClass logic)
MooseCompositeImporterTask
MooseSqueakClassPackageImporterTask ->
MoosePharoClassPackageExtractTask
MooseSqueakClasssCategoriesImporterTask -
>MoosePharoClassCategoriesExtractTask
MooseImportClassesTask -> MooseExtractClassesTask
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:33 p.m.
Hi,
On 13 Nov 2011, at 22:21, Stéphane Ducasse wrote:
--
www.tudorgirba.com
"Live like you mean it."
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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:
--
www.tudorgirba.com
Things happen when they happen,
not when you talk about them happening.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev MooseImportingTask - Renamed
SmalltalkImportingTask (add importerClass logic)
MooseCompositeImporterTask
MooseSqueakClassPackageImporterTask ->
MoosePharoClassPackageExtractTask
MooseSqueakClasssCategoriesImporterTask -
>MoosePharoClassCategoriesExtractTask
MooseImportClassesTask -> MooseExtractClassesTask
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:11 p.m.
ok
Now how do we proceed?
--
www.tudorgirba.com
"Live like you mean it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
14 Nov
14 Nov
7:55 a.m.
On 13 Nov 2011, at 23:11, Stéphane Ducasse wrote:
--
www.tudorgirba.com
"Live like you mean it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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.
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:49 a.m.
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:54 a.m.
Great.
Doru
On Mon, Nov 14, 2011 at 10:49 AM, Stéphane Ducasse <
stephane.ducasse(a)inria.fr> wrote:
hierarchy. Just
do not add the plugin mechanism in the importer.
Yes it should be above in the MooseTask
Stef
--
www.tudorgirba.com
"Every thing has its own flow"
ok
Now how do we proceed?
Just go ahead with your proposal of changing the names of the Task 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(a)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(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4787
days inactive
4793
days old
12 comments
3 participants
participants (3)
-
Stéphane Ducasse -
Tudor Girba -
Usman Bhatti