Re: Help understanding delegates?
"..delegate s aren't collections in the normal sense anyway."
What do you mean by that?
"..delegate s aren't collections in the normal sense anyway."
What do you mean by that?
-
-
Re: Help understanding delegates?
Brett <no@spam.com> wrote:[color=blue]
> "..delegate s aren't collections in the normal sense anyway."
>
> What do you mean by that?[/color]
Well, they don't implement ICollection, to start with.
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
-
Re: Help understanding delegates?
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1ce9e5 c492f51c7898c0d 5@msnews.micros oft.com...[color=blue]
> Brett <no@spam.com> wrote:[color=green]
>> "..delegate s aren't collections in the normal sense anyway."
>>
>> What do you mean by that?[/color]
>
> Well, they don't implement ICollection, to start with.[/color]
What benefits are there to using ICollection in this case? Isn't this still
a collection either way?
Brett
Comment
-
Re: Help understanding delegates?
Brett <no@spam.net> wrote:[color=blue][color=green][color=darkred]
> >> What do you mean by that?[/color]
> >
> > Well, they don't implement ICollection, to start with.[/color]
>
> What benefits are there to using ICollection in this case? Isn't this still
> a collection either way?[/color]
It's no a collection in any normal sense of being able to manipulate
it. Yes, there's an invocation list associated with the event, but you
can only add to it (at either end) or remove from it, both of which
create a new list rather than changing the existing one.
If you're going to use that broad a definition of "collection ", how
could you possibly say that collections in C#/.NET are unordered? An
array would count as a collection, and that *certainly* isn't
unordered. *Some* collections (usually maps) are unordered, but lists
are generally ordered.
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
-
Re: Help understanding delegates?
Brett <no@spam.com> wrote:[color=blue][color=green]
> > What do you mean by "get away with using a collection"?[/color]
>
> Perhaps it isn't a collection but just a list, as you have mentioned.[/color]
The delegate itself isn't a list - it encapsulates a list of
invocations, but it isn't a list in itself.
When you say that you "still get away with using a collection in this
case" what exactly do you mean?
[color=blue]
> Probably just do a GetType() to determine it.[/color]
I don't see how that would help. Could you give an example of what you
mean?
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
-
Re: Help understanding delegates?
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1ceb09 eb56cae6198c0e2 @msnews.microso ft.com...[color=blue]
> Brett <no@spam.com> wrote:[color=green][color=darkred]
>> > What do you mean by "get away with using a collection"?[/color]
>>
>> Perhaps it isn't a collection but just a list, as you have mentioned.[/color]
>
> The delegate itself isn't a list - it encapsulates a list of
> invocations, but it isn't a list in itself.
>
> When you say that you "still get away with using a collection in this
> case" what exactly do you mean?
>[color=green]
>> Probably just do a GetType() to determine it.[/color]
>
> I don't see how that would help. Could you give an example of what you
> mean?[/color]
I don't have an example. Was just trying to get a solid definition of what
this structure is that holds a list of events. First it was something that
behaved like a collection, then it was a list. Then not a list but
something encapsulating a list. One of us is very confused but I'm backing
off now. ; )
Thanks,
Brett
Comment
-
Re: Help understanding delegates?
Brett <no@spam.com> wrote:[color=blue][color=green]
> > I don't see how that would help. Could you give an example of what you
> > mean?[/color]
>
> I don't have an example. Was just trying to get a solid definition of what
> this structure is that holds a list of events. First it was something that
> behaved like a collection, then it was a list. Then not a list but
> something encapsulating a list. One of us is very confused but I'm backing
> off now. ; )[/color]
Basically, it contains a list. It's immutable, so you can't change the
list itself, only create a new delegate with a different list
containing the first list. You can't use it as a general purpose
collection, as it can only hold delegates.
The things you've said that confuse me most are:
1) That collections in C# aren't ordered
2) That you've used delegates as collections with no trouble
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
-
Re: Help understanding delegates?
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1ceb15 3963f48bd498c0e 4@msnews.micros oft.com...[color=blue]
> Brett <no@spam.com> wrote:[color=green][color=darkred]
>> > I don't see how that would help. Could you give an example of what you
>> > mean?[/color]
>>
>> I don't have an example. Was just trying to get a solid definition of
>> what
>> this structure is that holds a list of events. First it was something
>> that
>> behaved like a collection, then it was a list. Then not a list but
>> something encapsulating a list. One of us is very confused but I'm
>> backing
>> off now. ; )[/color]
>
> Basically, it contains a list. It's immutable, so you can't change the
> list itself, only create a new delegate with a different list
> containing the first list. You can't use it as a general purpose
> collection, as it can only hold delegates.
>
> The things you've said that confuse me most are:
>
> 1) That collections in C# aren't ordered[/color]
My fault.
[color=blue]
> 2) That you've used delegates as collections with no trouble[/color]
I thought they were collections. I've read they were in some of the online
examples I've seen. That's how they are described. That's not a global
description of course. Perhaps this exchange with Mattias further up in
the thread did me in. You see it hits both of your questions.
[>So is a delegate basically a collection of method pointers that when
called,[color=blue]
>executes all methods in the collection in the order they were added to the
>collection?[/color]
Correct, except that I believe the order they are called in is
undefined and implementation dependent.]
Comment
-
Re: Help understanding delegates?
In message <#5GnOOZVFHA.33 12@TK2MSFTNGP10 .phx.gbl>, Brett <no@spam.com>
writes[color=blue]
>[/color]
[color=blue][color=green]
>> 2) That you've used delegates as collections with no trouble[/color]
>I thought they were collections. I've read they were in some of the online
>examples I've seen. That's how they are described. That's not a global
>description of course.[/color]
I think this is just a case of terminology. It's quite common to use
"collection " to describe any container which can manage a number of
contained objects. I think Jon is using it in a stricter .NET specific
sense to mean "implements ICollection". I've got lots of classes
implementing IEnumerable which I would casually describe as
"collection s", but by Jon's definition, they aren't.
--
Steve Walker
Comment
-
Re: Help understanding delegates?
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1ceb15 3963f48bd498c0e 4@msnews.micros oft.com...[color=blue]
> Brett <no@spam.com> wrote:[color=green][color=darkred]
>> > I don't see how that would help. Could you give an example of what you
>> > mean?[/color]
>>
>> I don't have an example. Was just trying to get a solid definition of
>> what
>> this structure is that holds a list of events. First it was something
>> that
>> behaved like a collection, then it was a list. Then not a list but
>> something encapsulating a list. One of us is very confused but I'm
>> backing
>> off now. ; )[/color]
>
> Basically, it contains a list. It's immutable, so you can't change the
> list itself, only create a new delegate with a different list
> containing the first list. You can't use it as a general purpose
> collection, as it can only hold delegates.
>
> The things you've said that confuse me most are:
>
> 1) That collections in C# aren't ordered
> 2) That you've used delegates as collections with no trouble
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]
While we're on the subject,. how can I removed all events I've delegated?
For example:
IE_Inst.Documen tComplete -= new
SHDocVw.DWebBro wserEvents2_Doc umentCompleteEv entHandler(this .onIEDocComplet eGetMessages);
and at some later point clear out
IE_Inst.Documen tComplete
so that no event fires based on the page load complete.
Thanks,
Brett
Comment
-
Re: Help understanding delegates?
Brett <no@spam.com> wrote:[color=blue]
> While we're on the subject,. how can I removed all events I've delegated?
> For example:
>
> IE_Inst.Documen tComplete -= new
> SHDocVw.DWebBro wserEvents2_Doc umentCompleteEv entHandler(this .onIEDocComplet eGetMessages);
>
> and at some later point clear out
> IE_Inst.Documen tComplete
>
> so that no event fires based on the page load complete.[/color]
You can only remove specific handlers - so if you know what you've
added, you can remove them again - but you can't just clear out
everything.
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
-
Re: Help understanding delegates?
Jon Skeet [C# MVP] <skeet@pobox.co m> wrote in
news:MPG.1ceb25 fe50d8b98d98c0e 5@msnews.micros oft.com:[color=blue]
> You can only remove specific handlers - so if you know what you've
> added, you can remove them again - but you can't just clear out
> everything.[/color]
I think you would be able to iterate through the list of delegates (with
GetInvocationLi st) and remove each one. You probably can even tell whether
its something you've added (versus other classes) with the .Target and/or
..Method properties. Whether you can distinguish between two objects of the
same class with different events might be a bit more difficult, though.
-mdb
Comment
-
Re: Help understanding delegates?
mdb <m_b_r_a_y@c_t_ i_u_s_a__d0t__c om> wrote:[color=blue]
> Jon Skeet [C# MVP] <skeet@pobox.co m> wrote in
> news:MPG.1ceb25 fe50d8b98d98c0e 5@msnews.micros oft.com:[color=green]
> > You can only remove specific handlers - so if you know what you've
> > added, you can remove them again - but you can't just clear out
> > everything.[/color]
>
> I think you would be able to iterate through the list of delegates (with
> GetInvocationLi st) and remove each one. You probably can even tell whether
> its something you've added (versus other classes) with the .Target and/or
> .Method properties. Whether you can distinguish between two objects of the
> same class with different events might be a bit more difficult, though.[/color]
You can do that if you have access to the delegate - but if you only
have access to the *event*, you can't get the invocation list, only add
to it and remove from it.
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
-
Re: Help understanding delegates?
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1ceb32 731213ad3e98c0e 6@msnews.micros oft.com...[color=blue]
> mdb <m_b_r_a_y@c_t_ i_u_s_a__d0t__c om> wrote:[color=green]
>> Jon Skeet [C# MVP] <skeet@pobox.co m> wrote in
>> news:MPG.1ceb25 fe50d8b98d98c0e 5@msnews.micros oft.com:[color=darkred]
>> > You can only remove specific handlers - so if you know what you've
>> > added, you can remove them again - but you can't just clear out
>> > everything.[/color]
>>
>> I think you would be able to iterate through the list of delegates (with
>> GetInvocationLi st) and remove each one. You probably can even tell
>> whether
>> its something you've added (versus other classes) with the .Target and/or
>> .Method properties. Whether you can distinguish between two objects of
>> the
>> same class with different events might be a bit more difficult, though.[/color]
>
> You can do that if you have access to the delegate - but if you only
> have access to the *event*, you can't get the invocation list, only add
> to it and remove from it.[/color]
Using the example in my initial post, say I add two events to the deletgate
t0. Can I use a foreach loop to get at items stored in the t0 delegate
type?
Now, it isn't necessary that I implement IEnurmerable to use a for each
loop? I ask that question because every time I have used a for each loop, I
haven't implemented IEnumerable. However, from the docs:
[IEnumerable must be implemented to support the ForEach semantics of
Microsoft Visual Basic. COM classes that allow enumerators also implement
this interface.]
If the above is true, then t0 is a collection because IEnumerable is in the
System.Collecti ons namespace.
Brett
Comment
-
Re: Help understanding delegates?
"Brett" <no@spam.net> wrote in message
news:%23R5J5zcV FHA.4000@TK2MSF TNGP14.phx.gbl. ..[color=blue]
>
> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message[/color]
[Snip][color=blue][color=green]
>> You can do that if you have access to the delegate - but if you only
>> have access to the *event*, you can't get the invocation list, only add
>> to it and remove from it.[/color]
>
> Using the example in my initial post, say I add two events to the
> deletgate t0. Can I use a foreach loop to get at items stored in the t0
> delegate type?[/color]
IF you have access to the delegate object itself you can foreach through
Delegate.GetInv ocationList which is an array. Arrays implement IList which
inherits from IEnumerable via ICollection.
[color=blue]
> Now, it isn't necessary that I implement IEnurmerable to use a for each
> loop? I ask that question because every time I have used a for each loop,
> I haven't implemented IEnumerable. However, from the docs:
> [IEnumerable must be implemented to support the ForEach semantics of
> Microsoft Visual Basic. COM classes that allow enumerators also implement
> this interface.][/color]
The object you are enumerating on must implement IEnumerable (the one in the
"in" part of your foreach).
[color=blue]
> If the above is true, then t0 is a collection because IEnumerable is in
> the System.Collecti ons namespace.[/color]
Sorry, wrong. DictionaryEntry , Comparer, and IHashCodeProvid er are all in
the System.Collecti ons namespace and are not collections. Being in the
namespace does not imply that they ARE collections, merely that they are
related to collections in some way. You're confusing location with identity.
Just to reinforce my point, t0.GetInvocatio nList returns an array which IS a
collection (since it implements ICollection), but Array resides in the
System namespace.
[color=blue]
> Brett[/color]
Comment
Comment