 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / January 2008Registering Event Handlers in C# vs. VB .NET
Am I correct in thinking that because C# doesn't have the "Handles" keyword that VB .NET does, we have to register event delegates manually in C#, whereas in VB .NET using "Handles" takes care of registering the event delegate for us behind the scenes? In other words, *if* C# did have a "Handles"-type keyword, would we still need to register an event delegate? Scott, Yes, you are right, VB will take care of assigning the delegate to the event when you use the handles keyword. My assumption is that no, you would not have to register the event if something like that existed in C#, but it's impossible to say, given that there has been no discussion about it or mentioning of anything of that nature.  Signature- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com > Am I correct in thinking that because C# doesn't have the "Handles" > keyword that VB .NET does, we have to register event delegates manually [quoted text clipped - 3 lines] > In other words, *if* C# did have a "Handles"-type keyword, would we still > need to register an event delegate? Ok Nicholas. I just wanted to make sure my understanding of why we don't need to do it in VB .NET (and have a Handles keyword) equated to why we do have to do it in C# (and don't have something like Handles). Thanks! > Scott, > [quoted text clipped - 13 lines] >> In other words, *if* C# did have a "Handles"-type keyword, would we still >> need to register an event delegate? > Am I correct in thinking that because C# doesn't have the "Handles" > keyword [quoted text clipped - 4 lines] > In other words, *if* C# did have a "Handles"-type keyword, would we still > need to register an event delegate? As Nicholas says, it's hard to say what "might have been". That said, I prefer the C# approach. VB hides a bit of the mechanism from you, which IMHO makes it harder for people new to the whole delegates and events thing to really understand what's going on. It can be an especially difficult leap for a VB.NET programmer to grasp that a method written to handle an event can be applied to multiple events, multiple objects, etc. as well as that a given event can have multiple subscribers, because the basic syntax for dealing with event handlers in VB.NET doesn't expose that. Other people's opinions may vary. VB does a variety of things that smooth things out for the programmer, by inferring behaviors or doing things behind the scenes. I suppose some people might actually like this, but every time I see someone confused by what's going on in VB.NET, I wonder whether they would have had the same confusion had VB.NET not been invoking some hidden behavior on the programmer's behalf (another recent example that comes to mind is VB.NET instantiating a Form-derived class instance as some sort of "default" instance to use, conflicting with a previously-created one). Pete > It can be an especially difficult leap for a VB.NET programmer to grasp > that a method written to handle an event can be applied to multiple > events, multiple objects, etc. as well as that a given event can have > multiple subscribers, because the basic syntax for dealing with event > handlers in VB.NET doesn't expose that. Huh? In VB .NET, we often deal with multiple (or common) event handlers for multiple objects. We just use the Handles keyword to do it, but the concept is no more foreign in VB .NET than it is in C#. Also, while "Handles" does "hide" the underlying event delegate registration, working with delegates directly is not a problem at all and not hidden in any way. (using AddressOf). > Other people's opinions may vary. VB does a variety of things that smooth > things out for the programmer, by inferring behaviors or doing things [quoted text clipped - 5 lines] > instance as some sort of "default" instance to use, conflicting with a > previously-created one). I agree that "auto-instancing" of forms (gone in VB .NET 2002 & 2003 and back again in 2005) is contrary to good OO practice (and I personally discourage it's use), but I don't see how this is an example of hiding anything, since you can still instance forms explicitly if you wish. To me "hiding" means that what happens is completely behind the scense and you can't get involved with it. Delegates and auto-instancing of forms can be dealt with "automatically" (ie. Handles), but the concept isn't hidden and the developer can remove the Handles and use AddressOf to register their own delegates if they wish. Wouldn't you say the the C# "using" statement (now, in VB .NET 2005) "hides" some functionality in the same way that Handles does? Does that mean you wouldn't use "using"? It's just a language conveinience, but it doesn't hinder the language to have it available. ...My two cents - thanks for yours. -Scott >> It can be an especially difficult leap for a VB.NET programmer to grasp >> that a method written to handle an event can be applied to multiple [quoted text clipped - 11 lines] > directly is not a problem at all and not hidden in any way. (using > AddressOf). You've missed my point. I'm not saying VB.NET doesn't offer the same functionality possible elsewhere. I'm saying that the "Handles" keyword is used in a way that obscures the full capabilities of events. A particular example of what I mean is the requirement that when using "Handles" that you have some known object variable (as opposed, for example, to a collection of objects exposing an event), and of course the ability to subscribe and unsubscribe at will at run-time. It's not that you can't do these things in VB.NET, but you have to use an entirely different syntax to do so from the syntax offered up as the basic provided mechanism. > I agree that "auto-instancing" of forms (gone in VB .NET 2002 & 2003 and > back again in 2005) is contrary to good OO practice (and I personally > discourage it's use), but I don't see how this is an example of hiding > anything, since you can still instance forms explicitly if you wish. Again, you're missing my point. It's not about whether you _can_ do something. It's whether the supplied _basic_ mechanism hides from you the full functionality that is possible. I readily accept that some people prefer to have these details hidden from them, but it's not something I personally prefer and I've seen people have problems learning concepts like this when those details are hidden. > [...] > Wouldn't you say the the C# "using" statement (now, in VB .NET 2005) > "hides" > some functionality in the same way that Handles does? Does that mean you > wouldn't use "using"? No, I wouldn't say that "using" "hides" functionality in the same way that "Handles" does. There's a direct one-to-one mapping between "using" and the code it replaces. "Handles" offers a subset of the full spectrum of the way an event handling method can be used. > It's just a language conveinience, but it doesn't hinder the language to > have it available. I never said it hindered the language. I said it potentially hinders the programmer. > ...My two cents - thanks for yours. You're welcome. Hoepfully I've made myself better understood this time. Pete > You've missed my point. I'm not saying VB.NET doesn't offer the same > functionality possible elsewhere. I'm saying that the "Handles" keyword [quoted text clipped - 7 lines] > entirely different syntax to do so from the syntax offered up as the basic > provided mechanism. I didn't miss your point, but I think that your point doesn't apply as broadly as you make it sound. If I am developing my own classes and raising my own events, then the client of these classes won't have any "provided mechansim" for handling those events. It will be up to the client to declare the instance "WithEvents" or "AddHandler". I think what you are referring to is applicable to classes used in UI's, but then (as I said), they can still be modified to use the other syntax. I just don't think this is a VB thing. C# also has language elements, such as "using" that abstract a feature into a new language construct, but the user can still get at this language functionality in other ways. Anyway, thanks for your input. -Scott > I didn't miss your point, No, really...you did. I'm sorry I wasn't able to explain it sufficiently, but your replies make it clear you don't understand what I'm saying. It's probably my fault, but unfortunately I can't think of a better way to describe what I'm talking about. Pete No, really...I didn't. I just disagree. You're talking about the fact that VS .NET creates event handlers for UI elements and automatically wires up the events using "Handles", rather than creating the delegates and registering them using "AddHandler" and "AddressOf". And, you feel that because this happens automatically in UI applicaitons, VB .NET developers somehow won't understand what delegates are or have a harder time learning them than in C#. My point is that just because VS .NET chooses to write one syntax vs. the other doesn't mean that VB .NET developers are handicapped when it comes to learning and understanding delegates. Those developers writing custom classes and then using them in client applicaitons still have to create a mechansim for event handling and VS .NET doesn't offer any "standard" mechanism in those cases. Also, delegates are used for more than just event handling. So, anyone using VB .NET for any kind of serious development is going to be confronted with delegates and their useage beyond the "Handles" keyword. My analogy to you was the "using" keyword (originally added to C# and now to VB .NET 2005). Would using "using" in C# cause developers to have a harder time understanding what Dispose() is all about? No. In that case, "using" is just a compliment to the language, it enhances it. It's not required to use it - - you can still use the more manual Dispose() method call for clarity if you like, but "using" is just a short-cut, just like "Handles" is a short-cut for something you can still do manually (and in many cases, want to do manually). I think we just disagree on this one. -Scott >> I didn't miss your point, > [quoted text clipped - 6 lines] > > Pete > No, really...I didn't. I just disagree. No, you really don't get my point. > You're talking about the fact that VS .NET creates event handlers for UI > elements and automatically wires up the events using "Handles", rather > than > creating the delegates and registering them using "AddHandler" and > "AddressOf". Yes, I am talking about that fact. > And, you feel that because this happens automatically in UI > applicaitons, VB .NET developers somehow won't understand what delegates > are > or have a harder time learning them than in C#. That's not what I said. I said a specific subset of VB.NET developers may have problems grasping the full nature of events and delegates. As far as I'm concerned, that point is not even disputable. I've seen it happen. You can claim it's not a problem until you're blue in the face, I will still know from first-hand experience that's not true. I've no doubt that plenty of VB.NET programmers have no trouble. But that doesn't mean none do, nor does it mean that the choice to have two broadly different language mechanisms for using events has no effect on some developer's ability to get up to speed with certain .NET concepts. > My point is that just because VS .NET chooses to write one syntax vs. the > other doesn't mean that VB .NET developers are handicapped when it comes > to > learning and understanding delegates. I never said VB.NET developers are as a group handicapped. You continue to miss my point, even as you insist that you haven't. > [...] > I think we just disagree on this one. I don't mind a disagreement. But you need to understand my point before you disagree with it. Pete > I don't mind a disagreement. But you need to understand my point before > you disagree with it. If you were talking about a specific subset of VB people, why did you say: "It can be an especially difficult leap for a VB.NET programmer to grasp ..." It is only now that you are saying a specific set of VB programmers. Regardless, you can make that point about virtually any aspect of programming in any language. A specfiic set of C# programmers are going to have trouble understanding indexers. So what? Your new and improved "point" is really meaningless now. >> I don't mind a disagreement. But you need to understand my point before >> you disagree with it. [quoted text clipped - 4 lines] > "It can be an especially difficult leap for a VB.NET programmer to grasp > ..." Because that conveys my point better than writing "for VB.NET programmers", which is what I would have written had I meant to apply the discussion to ALL VB.NET programmers. In other words, I wrote that because it best conveyed the point I was, and have always been, trying to make. If you're having trouble understanding what I wrote, you might want to review the grammatical rules regarding the article "a". In particular, that word indicates a single instance, and isn't used to describe a plurality. > It is only now that you are saying a specific set of VB programmers. No. I have always been saying that. Just because you choose to read it differently, that doesn't change my intent or my words. It just means that you're unwilling to admit that you misunderstood all along. > Regardless, you can make that point about virtually any aspect of > programming in any language. A specfiic set of C# programmers are going > to > have trouble understanding indexers. So what? Your new and improved > "point" is really meaningless now. Whatever. Please feel free to come back to the discussion when you've learned how to carry on a civil conversation. Pete Geeze Peter, We're not going to debate what the meaning of "is" is are we? Without calling my college English professor, I think it's pretty obvious that your first post was not referring to any specific subset of VB developers, you wrote "a VB .NET programmer", you did not qualify the subset to which that programmer belongs in your estimation. Later on, you said that you have always been talking about a subset of VB programmers. It doesn't take a dictionary or an English major to see that you are now saying something different than before. You seem to just have a problem accepting that I do get what you are saying and I just disagree with it. >>> I don't mind a disagreement. But you need to understand my point before >>> you disagree with it. [quoted text clipped - 35 lines] > > Pete > We're not going to debate what the meaning of "is" is are we? > > Without calling my college English professor, I think it's pretty obvious > that your first post was not referring to any specific subset of VB > developers, you wrote "a VB .NET programmer", you did not qualify the subset > to which that programmer belongs in your estimation. Later on, you said This is incorrect. Peter did qualify which subset of VB .NET programmer he was discussing -- those for whom it (proper event handler registration) was a difficult concept to understand. Chris. Chris, That makes no sense. You are saying that the subset Peter describes as having a problem with understanding events are those who have trouble understanding events? No, go read his first post - he clearly says that a VB .NET developer will have trouble... He does not qualify any subset. -Scott >> We're not going to debate what the meaning of "is" is are we? >> [quoted text clipped - 9 lines] > > Chris. > Chris, > [quoted text clipped - 4 lines] > No, go read his first post - he clearly says that a VB .NET developer will > have trouble... He does not qualify any subset. He said "can", a potential, a possibility, not "will". I quote "It can be an especially difficult leap for a VB.NET programmer to grasp". If, picking a VB.NET programmer at random, the probability that said programmer has difficulty grasping the concept is non-zero, then the statement is accurate. This is both necessary and sufficient assuming that the pool of VB.NET programmers is finite, which if we discount the possibility of non-Earthlings somewhere having acquired VB.NET skills, is well founded. Since we've heard several examples of anecdotal evidence that at least some VB.NET programmers have been observed to have difficulty with that exact concept, the statement is accurate. Now I don't exactly agree with the way Peter sunk to ad-hominem attacks when his statement was questioned, but I think I've been at least that tactless at times so I will encourage all to simply forgive. > -Scott > [quoted text clipped - 11 lines] >> >> Chris. > [...] > Now I don't exactly agree with the way Peter sunk to ad-hominem attacks > when > his statement was questioned, but I think I've been at least that > tactless > at times so I will encourage all to simply forgive. For my own benefit, please point out the "ad-hominem attacks" to which you refer. I try very hard to _not_ use ad-hominem attacks and I believe that my posts demonstrate this very well. In this thread, it's true...I finally called a spade a spade, pointing out the basic jerk-like behavior on the part of Scott (he is at this point accusing me of being a liar). But that message came later, at a point when frankly I cannot find any other explanation for the continued debate other than that observation, and after Scott had already made his own personally-directed attacks. If I made an ad-hominem attack elsewhere, it was unintentional and if you could point it out that would help me understand better what you're talking about. Maybe I can avoid something like that in the future. Thanks, Pete I'm pretty sure I made no attacks, but stated politely that I disagreed and used those words to say so. I am also pretty sure I did not call you a liar or a jerk. So, who's doing the attacking? >> [...] >> Now I don't exactly agree with the way Peter sunk to ad-hominem attacks [quoted text clipped - 20 lines] > Thanks, > Pete > I'm pretty sure I made no attacks, but stated politely that I disagreed > and > used those words to say so. I am also pretty sure I did not call you a > liar > or a jerk. Every time you wrote that the point I originally made was different than the point I made later, you called me a liar. Why? Because you are unwilling to accept my original reply to you stating that you'd misunderstood my intent. It is reasonable for you to tell me I failed to express myself clearly, thus causing a misunderstanding. That was, in fact, my very first reply to your expressing an idea incompatible with what I wrote. But you rejected that possibility. It is also reasonable for you to tell me that I expressed myself clearly, but that you failed to understand in spite of that. You also rejected that possibility. It is ABSOLUTELY NOT REASONABLE for you to tell me that I meant something other than what I am telling you I meant but since you rejected the first two possibilities, this is the only possibility left. When you do that, you are accusing me of lying about what I originally intended and when you accuse me of lying I get very angry. I have been told that I can be somewhat unpleasant when I get angry. > So, who's doing the attacking? You. By refusing to accept my statements at face value, you accuse me of lying and thus are attacking me, and in a much worse way than had you just called me a jerk. I can readily accept that I can be a jerk sometimes, but when you tell me I'm a liar, you've crossed the line and I'm not going to just sit here and put up with it. Pete Peter, I shall be the last to attack Scott on his English, however you do. This is written in your original reply to the OP >It can be an especially difficult leap for a VB.NET programmer to grasp What would you tell us what was meant as was written: It can be an especially difficult leap for a person from (the country you are living in whatever it is) to be honest. Cor > Peter, > > I shall be the last to attack Scott on his English, however you do. No, it's _my_ English that is under attack. They are my words, and I am being told that I meant something other than what I meant when I wrote them. VERY IMPORTANT NOTE: this is _not_ about the meaning of the words themselves. It's about what I _meant_ when I wrote them. You can debate the semantic, literal meaning of the words I wrote all day long if you like, it has absolutely _nothing_ to do with the question at hand. I've already acknowledged the possibility that the words did not mean what I intended them to mean, but Scott has rejected that as a possible scenario. > This is written in your original reply to the OP > [quoted text clipped - 4 lines] > It can be an especially difficult leap for a person from (the country > you are living in whatever it is) to be honest. What was _meant_? No, I can't. You'd have to ask the author of the words to find out for sure what was _meant_. Out of context, it's not really possible to judge the meaning even just looking at the words, but regardless you cannot determine the _intent_ of the author without hearing from the author. Frankly, I'm amazed that anyone -- you or Scott -- could possibly take issue with what I've written. At _most_ there should only be a misunderstanding due to a poor choice of words, but since I offered that possibility right at the beginning and it was immediately rejected, the only thing that's left is people accusing me of being a liar. I made a good-faith effort to try to resolve the misunderstanding, but Scott would not accept that. Instead, he insisted on continuing his attack on my statement, and transitively on me as well. You have chosen to support that attack, which IMHO puts you in just as bad a light as Scott has already put himself. Are you really sure that's where you want to be? Pete > I've already acknowledged the possibility that the words did not mean what > I intended them to mean, but Scott has rejected that as a possible > scenario. OK, missed that, Sorry than for my reply. Cor >> Peter, >> [quoted text clipped - 12 lines] > I intended them to mean, but Scott has rejected that as a possible > scenario. The interesting thing here is that Peter's original statement is perfectly fine, it doesn't make the broad-sweeping claim that Scott took issue with. However Peter, you did directly attack Scott on his English, as Cor said. I quote: "If you're having trouble understanding what I wrote, you might want to review the grammatical rules regarding the article "a"." > [...] > However Peter, you did directly attack Scott on his English, as Cor [quoted text clipped - 3 lines] > "If you're having trouble understanding what I wrote, you might want to > review the grammatical rules regarding the article "a"." Really? That's an attack? Given your statement that my original statement was perfectly clear, are you saying that for someone having trouble understanding it, it would _not_ be helpful to review the grammatical rules regarding the article "a"? It seems to me that if every time someone offers a suggestion as to how they might rectify an apparent gap in their knowledge, that this newsgroup is chock full of attacks. Pete >> [...] >> However Peter, you did directly attack Scott on his English, as Cor [quoted text clipped - 5 lines] > > Really? That's an attack? I can't quite explain why, but my gut feel as a native English speaker is that the particular phrasing you had chosen there is a tad on the insulting side. Moreso than, for example, "That's not the right way to use pass-by-reference, Jon Skeet has written up an excellent explanation at <don't remember the URL>" > Given your statement that my original statement was perfectly clear, are > you saying that for someone having trouble understanding it, it would > _not_ be helpful to review the grammatical rules regarding the article > "a"? I didn't say it was clear. I said it was correct. Certainly it should have been clear after your explanation. > It seems to me that if every time someone offers a suggestion as to how > they might rectify an apparent gap in their knowledge, that this newsgroup > is chock full of attacks. Well I'm certainly not wanting to get into a spat here. I'm just trying to share the connotations I get from a particular sentence, especially since you said "For my own benefit, please point out the "ad-hominem attacks" to which you refer." After all, as members of the tech community we have to deal with a lot of different cultures and thus have to try and learn what other people might take as an affront. I know I've been quite obnoxious at times and I'm just trying to learn better myself. I surely do think that this whole issue has been blown WAAAAY out of proportion, and the only real cause I can think of is that you might have hit a sore spot with someone who secretly codes in VB. <sarcasm>Of course, you (and I) are all lamers for not writing everything in assembler.</sarcasm> > Pete > [...] > Well I'm certainly not wanting to get into a spat here. I'm just trying [quoted text clipped - 3 lines] > to > which you refer." Fair enough. My own interpretation of "ad-hominem" wouldn't include something like what you quoted -- that statement was a) factually correct, and b) not exactly a direct insult in the way that I view actual ad-hominems to be -- but perhaps it was taken as more of an attack than was intended. I appreciate you pointing it out, and in fact it's just this sort of thing -- something that makes me say "huh? someone was offended by that?" -- that I can probably use help with. Of course, to some extent I'm less worried about a particular instance of something like that. It's hard to get very apologetic about a perceived glancing blow like that one, when a direct accusation of lying is being leveled at me. > [...] > I surely do think that this whole issue has been blown WAAAAY out of > proportion, and the only real cause I can think of is that you might have > hit a sore spot with someone who secretly codes in VB. Maybe. Which is ironic, as I have never expressed or held the opinion that the language one codes in is reflective of their abilities as a programmer. Some languages may be easier, and thus allow _some_ of the users of the language to get by with sub-par skills, but you can't tell anything about a particular person by what language they use. For someone to think that I was saying they are a lesser programmer just because they use a particular language is laughable, and would in fact been a moment of great hilarity had it not been for Scott's obstinate insistence that he knew not only exactly the meaning of the words I wrote, but my own intent behind them, when in fact it was clear to me that he knew neither. Pete > We're not going to debate what the meaning of "is" is are we? No, why should we? I won't waste my time trying to offer you a grammar education. > Without calling my college English professor, I think it's pretty obvious > that your first post was not referring to any specific subset of VB > developers, you wrote "a VB .NET programmer" Call your college English professor, I don't care. Your assertion of what's "obvious" is self-serving and contrary to a common-sense interpretation of what I wrote. I have no idea why you've decided to take on the burden of being so offended, in spite of my original text being reasonably clear. Even if it wasn't (and you're the only person who seems to have trouble getting it, so that seems unlikely), I have provided more than sufficient clarification. Only a complete jerk would continue to persist on insisting that they know better than the author of the original words what the intent of those words are. So, if you want to hold on to your perception of offense, to feed whatever dark part of your soul seems so hungry for conflict and persecution, far be it from me to continue to try to disavow yourself of that. But make no mistake: that's your own choice and it has nothing at all to do with the reality of the situation. > [...] It > doesn't take a dictionary or an English major to see that you are now > saying > something different than before. No, but it does take someone who simply cannot admit that they have misread something that was plain enough to everyone else. > You seem to just have a problem accepting that I do get what you are > saying > and I just disagree with it. It only seems that way to _you_. Of course, you are not an unbiased observer, having committed yourself several times to the assertion that you _did_ understand what I wrote. To admit now that you were wrong would, apparently, cost your ego far too much to go through with that admission. The thing I find funniest about this whole exchange is that early on, I even acknowledged the possibility that I hadn't expressed myself well enough to make myself understood, and you continued on insisting that you knew exactly what I meant, even though it was clear enough to me that you didn't. There's just no plausible claim that I have any motivation whatsoever to backpedal on my original statement. The only cost to me would be admitting I hadn't expressed myself well enough, and I've already done as much. What possible cause would I have at this point to contradict what you're saying, other than a general belief in the truth? No, it's very clear that you are the only person here with any motivation to refuse to admit fault. That makes it painfully obvious that this disagreement continues only because of your inability to admit you didn't understand what I wrote in the first place. Get over it. Ironically, if you'd just accepted my apology for not making myself understood in the first place, you wouldn't even feel backed into the corner you do. At that point, you could have just called it my fault and been done with it. Instead, you continued to insist that you understood, leaving you here without any way to acknowledge the truth in what I'm saying without admitting a mistake on your own part. You really need to learn to admit to your mistakes. It's not actually all that painful to do, and it will really help you avoid looking like such an ignorant jerk in the future (sorry, it's too late for you in this thread). Pete > My analogy to you was the "using" keyword (originally added to C# and now to > VB .NET 2005). Would using "using" in C# cause developers to have a harder [quoted text clipped - 4 lines] > a short-cut for something you can still do manually (and in many cases, want > to do manually). I think the whole using thing is a terrible counter-example, because it is rather clear that it only affects one block, and troubleshooting a misunderstanding of this is in most cases trivial. The VB.NET syntax issue Peter pointed out was more a case of asking the question: How is a newbie programmer going to understand that when they have a method that "Handles" an event that other things could already also be handling the event? While I could see the same newbie programmer failing to grasp that his object in the using statement is no longer available after the following block, that is a fairly straightforward thing to troubleshoot, and the errors in the code will be rather apparent. From personal experience, I've seen developers (in the process of learning) just assume that because it says the method "Handles" the event, that only their method handles the event. Whether you want to insult their intelligence or learning methods is really irrelevant, what it boils down to is I've seen it cause confusion. Most of the time explaining it using the alternate syntax (AddHandler/RemoveHandler) seems to clear it up, because they then get it's a list of Handlers, not just one method doing it all. This is of course not a discussion of one language being superior to the other or anything like that. Pete just said he didn't like the keyword because in his experience (obviously similar to my own) it can/does lead to confusion. What this amounts to is arguing about someone else's personal experience. Chris. <snip> > This is of course not a discussion of one language being superior to the other > or anything like that. Pete just said he didn't like the keyword because in his > experience (obviously similar to my own) it can/does lead to confusion. What > this amounts to is arguing about someone else's personal experience. It has another rather sneaky side-effect too - it turns fields into properties in order to subscribe/unsubscribe. FWIW, I believe that the "field-like events" syntax of C# has also done developers a disservice in many ways - it's caused a lot of confusion about what events really are. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk > It has another rather sneaky side-effect too - it turns fields into > properties in order to subscribe/unsubscribe. > > FWIW, I believe that the "field-like events" syntax of C# has also done > developers a disservice in many ways - it's caused a lot of confusion > about what events really are. Yeah, ultimately I think developing a language is about trying to maintain the delicate balance between Clarity, Simplicity, and Utility. People just have different ideas of what those things mean. Chris. I think a lot of this boils down to what Nigel Shaw once referred to as the "culture" from which each language came. C# was created from the ground up specifically to target the .NET Framework whereas VB.NET "came from" the original classic Visual Basic - which "came from" the original BASIC, and so on, ad nauseum. -- Peter Site: http://www.eggheadcafe.com UnBlog: http://petesbloggerama.blogspot.com MetaFinder: http://www.blogmetafinder.com > > It has another rather sneaky side-effect too - it turns fields into > > properties in order to subscribe/unsubscribe. [quoted text clipped - 9 lines] > > Chris. >I think a lot of this boils down to what Nigel Shaw once referred to as the > "culture" from which each language came. C# was created from the ground up [quoted text clipped - 3 lines] > on, ad nauseum. > -- Peter Again, I disagree here. VB .NET was also created from the ground up specifically to target the .NET Framework, but compatibility measures were added in as not to alienate the millions of VB 6 developers. C# was written from the ground up with C and Java in minde to accomodate those millions of developers. > >I think a lot of this boils down to what Nigel Shaw once referred to as the > > "culture" from which each language came. C# was created from the ground up [quoted text clipped - 7 lines] > from the ground up with C and Java in minde to accomodate those millions of > developers. While I see your point, the "compatibility measures" involved are *vastly* different between C# and VB.NET. There are plenty of syntactic similarities, but equally large differences - and there are very few bits of code which will work in both C/C++/Java and C#. Just as an indicator of this, there's no add-on library to make C# behave like C, C++ or Java - unlike VB.NET. (J# is a different beast, of course.) SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk Peter, >I think a lot of this boils down to what Nigel Shaw once referred to as the > "culture" from which each language came. C# was created from the ground up > specifically to target the .NET Framework whereas VB.NET "came from" the > original classic Visual Basic - which "came from" the original BASIC, and > so > on, ad nauseum. I find that you are very negative writing about C#. It has inherited a lot of the good things from other program languages (including VB6). I would sure not compare it in a direct line with the first program languages which were developed as you do, however you are of course free to do that. By the way the culture shock for the VB6 users to the first VB for Net, was much more then those who came from the then existing C type program langages to C#. The way VB was first changed was dramatic for some. There has been later added a lot to VB to let the classic VB users as well accept it. (Not that I like "those" additions). An example Jon Skeet writes side by side Java and C# as far as I know. (Although I have seen he becomes beter and beter in VB for Net too). Cor Peter, > That said, I prefer the C# approach. It is not a C# approach the short way in VB is something extra in VB and very documentative and therefore very easy to maintain in 95% of the situations. That is probably the reason that it is mostly used in VB. I would be pleased if it was in C# as well as that extra. Cor >> Am I correct in thinking that because C# doesn't have the "Handles" >> keyword [quoted text clipped - 28 lines] > > Pete In keeping with VB's philosophy of having many ways to do the same thing, you can either use "Handles" or "AddHandler" (AddHandler and RemoveHandler are the exact equivalent to the C# approach). Signaturehttp://www.tangiblesoftwaresolutions.com C++ to C# C++ to VB C++ to Java C++ to Ruby Instant C#: VB to C# converter Instant VB: C# to VB converter Instant C++: convert VB or C# to C++/CLI > Am I correct in thinking that because C# doesn't have the "Handles" keyword > that VB .NET does, we have to register event delegates manually in C#, [quoted text clipped - 3 lines] > In other words, *if* C# did have a "Handles"-type keyword, would we still > need to register an event delegate? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.