Re: [Springnet-developer] ScheduledThreadPoolExecutor
Brought to you by:
aseovic,
markpollack
|
From: Mark P. <mar...@sp...> - 2008-02-19 16:07:35
|
Hi, I'd rather have a clean 'generic' only interface contract for IQueue<T> and therefore not inherit from IQueue and considering that IQueue isn't widely used, we can afford to make that change unlike the case with IList<T>/IList in the BCL. Cheers, Mark -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Griffin Caprio Sent: Monday, February 18, 2008 5:11 PM To: spr...@li... Subject: Re: [Springnet-developer] ScheduledThreadPoolExecutor <Moving this to the Spring.NET Dev group> Pascal, Not sure I follow the ThreadPool reference. Can you expand on it a little? MSN: gri...@ho... - Griffin On Feb 18, 2008, at 3:46 PM, Pascal Vantrepote wrote: > For Collections it's not a big deal. You do not change Collection > every release (Collections are quit steady). > It might be an issue for other type of class (ThreadPool), but I > don't see why. > > By the way, are you guys using MSN? > > Pascal. > > > On 18-Feb-08, at 4:36 PM, Griffin Caprio wrote: > >> Ah, i see. I guess that makes sense from a compatibility >> standpoint, but it creates a HUGE maintenance nightmare because >> then we're basically creating one class that conforms to two >> interface contracts. Off the top of my head, I would bet that >> means we'll have to make concessions when implementing features >> inside classes that implement the IQueue<T> interface. >> >> Though, I could just be overestimating the cost of supporting two >> interfaces. >> >> - Griffin >> On Feb 18, 2008, at 3:26 PM, Pascal Vantrepote wrote: >> >>> Yes, that what I mean. >>> Sorry I was not clear. >>> English is not my first language. Sorry again. >>> >>> Pascal. >>> >>> On 18-Feb-08, at 4:24 PM, Griffin Caprio wrote: >>> >>>> Pascal, >>>> >>>> I'm not sure I understand. If a user had written something with >>>> a IQueue paramter, why would that change with the introduction of >>>> IQueue<T> unless they wanted to take advantage of the generic >>>> interface. Then, they would just change the parameter to >>>> IQueue<T> and move on. Do you mean that it would be easier for >>>> the user to pass in an instance of a IQueue<T> class, since it >>>> inherits from IQueue? >>>> >>>> - Griffin >>>> >>>> On Feb 18, 2008, at 3:21 PM, Pascal Vantrepote wrote: >>>> >>>>> That was the idea (having Spring.Threading.Generic...) and sorry >>>>> I did not develop the idea in my previous mail. >>>>> >>>>> Now, having Generic inherit from non generic is to keep >>>>> compatibility with already written non generic class. >>>>> Like Microsoft is doing with IList<T> : IList. >>>>> By this way if a user already wrote a class using IQueue has a >>>>> parameter, he doesn't have to rewrite his class. >>>>> Is it ok for you? >>>>> >>>>> Thanks. >>>>> Pascal >>>>> >>>>> On 18-Feb-08, at 1:46 PM, Mark Pollack wrote: >>>>> >>>>>> Hi Pascal, >>>>>> >>>>>> I certainly agree that it would make more sense if IQueue<T> is >>>>>> defined in >>>>>> Spring.Core and that is the end goal. Putting such classes in >>>>>> the namespace >>>>>> Spring.Collections.Generic would seem like a natural location >>>>>> considering we >>>>>> already have a non generic namespace and it would mirror >>>>>> System.Collections.Generic. We wouldn't remove what is >>>>>> currently in >>>>>> Spring.Collections even if we support only >= .NET 2.0. >>>>>> >>>>>> In any case, since we would like to have much more than >>>>>> IQueue<T> put under >>>>>> Spring.Collections.Generic, why don't you create that namespace >>>>>> in the >>>>>> Spring.Threading project? This way once Spring.Threading is >>>>>> properly >>>>>> 'incubated' under this umbrella project of Spring Extensions we >>>>>> can easily >>>>>> move it into the main code base. If it is an urgent matter of >>>>>> adding a few >>>>>> classes into Spring.Core that would make development for you >>>>>> much easier >>>>>> right now, we can consider doing that, but I think it would be >>>>>> a good idea >>>>>> for all of the classes in Spring.Threading to have the same >>>>>> 'bake time'. >>>>>> >>>>>> Sound ok? >>>>>> >>>>>> BTW: Isn't inheriting IQueue<T> from IQueue defeating the >>>>>> purpose of having >>>>>> generics? I would have thought a generic version would imply a >>>>>> cut-n-paste >>>>>> reuse of existing IQueue interfaces and implementing classes? >>>>>> >>>>>> Cheers, >>>>>> Mark >>>>>> >>>>>> -----Original Message----- >>>>>> From: Pascal Vantrepote [mailto:pva...@gm...] >>>>>> Sent: Monday, February 18, 2008 1:04 PM >>>>>> To: Mark Pollack >>>>>> Cc: 'Griffin Caprio' >>>>>> Subject: Re: ScheduledThreadPoolExecutor >>>>>> >>>>>> Just to be able to have Generic for Collection in Spring.Core. >>>>>> It will be easier if IQueue (defined in Spring.Core) was Generic >>>>>> (IBlockingQueue inherit from IQueue). >>>>>> >>>>>> For now I can create a Generic IQueue (in Threading) inherited >>>>>> from >>>>>> the non Generic IQueue. >>>>>> The day, a decision is made to drop support of .NET 1.1, the >>>>>> definition can move from Threading to Core. >>>>>> >>>>>> But for me it make more sense if IQueue<T> is define in >>>>>> Spring.Core. >>>>>> >>>>>> Let me know >>>>>> Pascal. >>>>>> >>>>>> >>>>>> On 18-Feb-08, at 12:46 PM, Mark Pollack wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Great to see this progress! I'm working on getting the svn >>>>>>> stuff >>>>>>> setup. >>>>>>> >>>>>>> Adding generics support in Spring.Core hasn't been fully >>>>>>> scoped out >>>>>>> yet. At >>>>>>> the moment there is some debate if we should hold off doing >>>>>>> that until >>>>>>> Spring.NET 2.0 in which case we would also drop support >>>>>>> for .NET 1.0 >>>>>>> and >>>>>>> 1.1. In any case, I don't see Spring.Threading functionality >>>>>>> places >>>>>>> this >>>>>>> requirement on Spring.Core. Can you explain? >>>>>>> >>>>>>> Cheers, >>>>>>> Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pascal Vantrepote [mailto:pva...@gm...] >>>>>>> Sent: Monday, February 18, 2008 12:09 PM >>>>>>> To: Griffin Caprio; Mark Pollack >>>>>>> Subject: ScheduledThreadPoolExecutor >>>>>>> >>>>>>> Hey Guys, >>>>>>> >>>>>>> I have good news. The port of ScheduledThreadPoolExecutor is >>>>>>> done. >>>>>>> Do you want me to send the files (I had to modify FutureTask and >>>>>>> IBlockingQueue) or wait until the repository is up? >>>>>>> >>>>>>> I think it was the last not implemented class. Griffin can >>>>>>> confirm >>>>>>> that, please? >>>>>>> So next step is to add Generic support. >>>>> >>>> >>> >> > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer |