Delegates

[Leo Sutic <le...@inspireinfrastructure.com>]

Berin,

regarding delegates.

 1) I want them too.

 2) They are cool.

 3) Events are cool too.

 4) They don't belong in Excalibur/Util, because they are more than just
    utilities for Excalibur.

 5) They don't belong in Excalibur, because Excalibur is supposed to
    be Avalon-specific. (That's why we're throwing out Collections).

 6) They don't belong in Framework. 

 7) They are really language-level constructs.

Therefore I suggest we try to get them into Commons/Lang.

I think it is OK for Excalibur to have dependencies on Commons,
plus having them there will increase the likelyhood of adoption.

Opinion?

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Delegates

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> Leo Sutic wrote:
>
> My best guess is that the Event is a form of delegate that 
> has multiple methods respond to the same invokation.  In that 
> respect, it is still a Delegate in its true sense--but it 
> follows the addition/subtraction semantics of C# delegates.

I think my Event is what is an event in C#. 

Essentially, an Event (as I used the word), is a delegate that
does not return anything (returns void), and that can be
multicast.

So, while a delegate is a method pointer, an event is a list
of method pointers, and when you fire the event, you go down the
list and call each.

So delegates are used when you want a return value, and when
you can be sure there's only *one* method that should be called.

Events are for the publisher/subscriber relationship when you have
multiple subscribers.

> We should probably come up with a better name for it than 
> Event.

Yes... Uh... Multicast? Subscriber? DelegateEvent? Broadcast?

> Lets throw this thing together in Util, shake out the bugs, 
> and then attempt to donate it to Commons-dev [lang].

Yes.

Do you know how responsive commons-dev is to patches? On one hand,
we should get it to commons as soon as possible. On the other hand,
the moment we turn it over, (at least I) don't have committer access
to the code anymore.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Delegates

[Berin Loritsch <bl...@apache.org>]

Leo Sutic wrote:
> Berin,
> 
> regarding delegates.
> 
>  1) I want them too.
> 
>  2) They are cool.
> 
>  3) Events are cool too.

I would like to understand your definition of Event.  In the Excalibur
Event package, they can be just about anything.  I am curious how this
bears out in your thinking.

We both agree on the definition of Delegate, and your DelegateFactory
is probably more true to what a delegate is.  My best guess is that
the Event is a form of delegate that has multiple methods respond to
the same invokation.  In that respect, it is still a Delegate in its
true sense--but it follows the addition/subtraction semantics of C#
delegates.

We should probably come up with a better name for it than Event.

Lets throw this thing together in Util, shake out the bugs, and then
attempt to donate it to Commons-dev [lang].



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Delegates

[Berin Loritsch <bl...@apache.org>]

Leo Sutic wrote:
> 
>>From: Berin Loritsch [mailto:bloritsch@apache.org] 
>>
>>Util is a scratchpad.
> 
> 
> Oh.
>  
> 
>>Leo Sutic wrote:
>>
>>>Berin,
>>>
>>>Therefore I suggest we try to get them into Commons/Lang.
>>
>>Your version would make it.  I am using Excalibur as a 
>>scratchpad in this case.
>>
>>
>>>I think it is OK for Excalibur to have dependencies on 
>>
>>Commons, plus 
>>
>>>having them there will increase the likelyhood of adoption.
>>>
>>>Opinion?
>>
>>True.  However in order for it to be in Lang, it cannot be in 
>>its current form.  I will try adapting it to your form (the 
>>factory pattern).
> 
> 
> Well, the code I sent is ready to go. I have an improved version 
> with synchronization for the event class, so you won't get weird 
> behaviour when someone registers an event while it is firing.
> 
> Plus, it has some extra checks... It's better, simply put.
> 
> OK, so how about some collaboration on this?
> 
> I can put a cleaner, better version of my code into Excalibur/Util.
> Since I barfed out the code, I get to clean it up and commit it?
> 
> Plus, it is in a desperate need of documentation, and I think
> I am the one most suited to write that (since I wrote the code).

Don't forget TestCases.  I modified the one I had for the old
Delegate style.  Delegate is taken care of.  The Event stuff is
all you need to do.

BTW, we are both listed as authors on the Delegate.  The original
idea came from me, plus the extra checking, but the larger design
came from you.  I like it alot better.

> Then, once we are confident that it works, we contact Commons/Lang
> and try to get it in there. Maybe in commons.lang or
> commons.lang.delegate.

Delegate works.  All we need now is Event to work!


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Delegates

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> Util is a scratchpad.

Oh.
 
> Leo Sutic wrote:
> > Berin,
> > 
> > Therefore I suggest we try to get them into Commons/Lang.
> 
> Your version would make it.  I am using Excalibur as a 
> scratchpad in this case.
> 
> > I think it is OK for Excalibur to have dependencies on 
> Commons, plus 
> > having them there will increase the likelyhood of adoption.
> > 
> > Opinion?
> 
> True.  However in order for it to be in Lang, it cannot be in 
> its current form.  I will try adapting it to your form (the 
> factory pattern).

Well, the code I sent is ready to go. I have an improved version 
with synchronization for the event class, so you won't get weird 
behaviour when someone registers an event while it is firing.

Plus, it has some extra checks... It's better, simply put.

OK, so how about some collaboration on this?

I can put a cleaner, better version of my code into Excalibur/Util.
Since I barfed out the code, I get to clean it up and commit it?

Plus, it is in a desperate need of documentation, and I think
I am the one most suited to write that (since I wrote the code).

Then, once we are confident that it works, we contact Commons/Lang
and try to get it in there. Maybe in commons.lang or
commons.lang.delegate.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Delegates

[Berin Loritsch <bl...@apache.org>]

Leo Sutic wrote:
> Berin,
> 
> regarding delegates.
> 
>  1) I want them too.
> 
>  2) They are cool.
> 
>  3) Events are cool too.
> 
>  4) They don't belong in Excalibur/Util, because they are more than just
>     utilities for Excalibur.
> 
>  5) They don't belong in Excalibur, because Excalibur is supposed to
>     be Avalon-specific. (That's why we're throwing out Collections).
> 
>  6) They don't belong in Framework. 
> 
>  7) They are really language-level constructs.
> 
> Therefore I suggest we try to get them into Commons/Lang.


Your version would make it.  I am using Excalibur as a scratchpad
in this case.

> I think it is OK for Excalibur to have dependencies on Commons,
> plus having them there will increase the likelyhood of adoption.
> 
> Opinion?

True.  However in order for it to be in Lang, it cannot be in its
current form.  I will try adapting it to your form (the factory
pattern).


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>