13 Nov
2011
13 Nov
'11
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