Re: [Springnet-developer] ScheduledThreadPoolExecutor

[Mark P. <mar...@sp...>]

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