Re: [Springnet-developer] ScheduledThreadPoolExecutor

[Griffin C. <gri...@ma...>]

+1

- Griffin

On Feb 19, 2008, at 10:07 AM, Mark Pollack wrote:

> 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
>
>
> -------------------------------------------------------------------------
> 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