tag:blogger.com,1999:blog-3760169963830810897.post1890524750932780672..comments2023-03-26T21:00:59.091+01:00Comments on Code Butchering: [.NET vs Java] Event Handling: Are you sure pure OOP is always the simplest?Anonymoushttp://www.blogger.com/profile/13431481971279629409noreply@blogger.comBlogger21125tag:blogger.com,1999:blog-3760169963830810897.post-25959587001656343662008-09-29T00:17:00.000+01:002008-09-29T00:17:00.000+01:00ok I have nothing more to say, you defeat me with ...ok I have nothing more to say, you defeat me with le lambda calculusEnrico Murruhttps://www.blogger.com/profile/13544715040561543958noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-33643931257479165842008-09-28T19:28:00.000+01:002008-09-28T19:28:00.000+01:00it seems to me that treating methods as objects is...<I>it seems to me that treating methods as objects is a little forced concept, don't you think?</I><BR/><BR/>No, definitely not. First-class functions have been a key part of programming since the discipline was first developed. They are core to the lambda calculus, which is one of the foundations of CS.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-88629531159407751452008-09-27T01:40:00.000+01:002008-09-27T01:40:00.000+01:00Scuffia - congrats for your English, it's horrible...Scuffia - congrats for your English, it's horrible.<BR/><BR/>To raise events is common practice in .NET - even among butchers, you'll seeAnonymoushttps://www.blogger.com/profile/13431481971279629409noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-15071676656413065212008-09-27T00:49:00.000+01:002008-09-27T00:49:00.000+01:00to bobisbob, it seems to me that treating methods ...to bobisbob, it seems to me that treating methods as objects is a little forced concept, don't you think? anyway you're right saying that as Methods are objects, .NET is more OOP than Java (or at least as OOP as).<BR/>actually I've never had the need to raise an event, anyway I believe in you when you say that is a usefull and used pattern: let's see in my next works!Enrico Murruhttps://www.blogger.com/profile/13544715040561543958noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-85390929467600769902008-09-26T22:47:00.000+01:002008-09-26T22:47:00.000+01:00let's just say delegates are a kind of function po...<I>let's just say delegates are a kind of function pointers</I><BR/><BR/>It's a little closer to the truth to think of them as function pointers bundled with a "this" reference.<BR/><BR/><I>For common applications, you won't need to raise yourself an event</I><BR/><BR/>Once you're fully versed with C#, you'll find this not to be true. It's very common to create your own events in classes once you're comfortable with the concept.<BR/><BR/><I>In that situation Java is more OO then .NET</I><BR/><BR/>Not really. Delegates are objects in C#. In fact, the fact that methods themselves can be treated like objects in C#, unlike Java, would imply that it's <I>more</I> OOP.<BR/><BR/><I>Moreover, in .NET you won't need to specify an entire class to handle the event, bringing to a more concise code style.</I><BR/><BR/>More importantly, in C# you can listen to the same event from different sources in the same class, and handle them separately. (For example, listen to OnClick handlers from two buttons in the same window class.) In Java, you have to resort to inner classes (ugh) to do it.<BR/><BR/><I>tarelli: Following that idea C# could introduce new syntax to the language to create singletons if they feel like.</I><BR/><BR/>They did. static constructors. Works exactly like you'd expect: where static methods don't need an instance, the static constructor doesn't either. It will be called automatically before any method is called.<BR/><BR/>You could do that yourself, but it would mean wrapping every single method in your class with lazy initialization code.<BR/><BR/><I>In my opinion for delegates the benefits worth to justify them to be treaten as an exception</I><BR/><BR/>Personally, I think they're simpler to learn and use than anonymous inner classes. Once you throw in closures, they become <I>very</I> useful for a relatively small addition to the syntax.<BR/><BR/><I>fsilber: Is an event something that happens, or is an event object a piece of fuctionality that gets executed _when_ something happens?</I><BR/><BR/>It's something that happens (specifically, it is "raised"). The thing executed is an "event handler".Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-16530826114779292232008-09-23T14:21:00.000+01:002008-09-23T14:21:00.000+01:00fsilber,I think you're splitting hairs. First, Mi...fsilber,<BR/><BR/>I think you're splitting hairs. First, Microsoft doesn't say "adding delegates to events". They say "adding handlers to events". I think any English speaking person can easily comprehend that. If you want to get into silly word wars, I'd say that Java's concept of "listening to events" makes little sense. Events make noise? Observing the events makes a whole lot more sense.<BR/><BR/>Sorry, you're just spouting off, and contributing nothing with this argument. You're picking nits over something as unimportant as this, while YOU use terms and provide definitions that aren't accurate (referring to your remarks about closures). Takes away most of the emotional strength of your argument.wekempfhttps://www.blogger.com/profile/05888776726588158230noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-8025698130320994632008-09-23T04:18:00.000+01:002008-09-23T04:18:00.000+01:00To wekempf: Java does not add listeners to events...To wekempf: Java does not add listeners to events; it adds event handlers/listeners to event-producing components. The latter makes sense; "adding delegates to events" is gibberish.<BR/><BR/>Note that I am not criticizing the programming model of C#; in many ways I think it is a better language than Java. My criticism was limited to Microsoft's typical cavalier use (i.e. abuse) of the English language in the choice of keywords and identifiers. (It suggests to me that all too many of their developers' attention fails to rise above the level of operations and mechanisms to think in terms of declarative concepts.)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-70631323164165933342008-09-22T20:48:00.000+01:002008-09-22T20:48:00.000+01:00"Would you like more public singleton class MyClas..."Would you like more public singleton class MyClass{...} because the code is more concise?"<BR/><BR/>No. I'd like it because it's less error-prone and less repetitive. Scala has it: object MyObject { }Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-11812100467325530042008-09-22T17:40:00.000+01:002008-09-22T17:40:00.000+01:00IMHO a delegate is someone that acts for you when ...IMHO a delegate is someone that acts for you when something (an event) happens...it doesn't seem so strange sintactically (Rice won't be a delegate for Bush for an earthquake but for a meeting I suppose it's right!).Enrico Murruhttps://www.blogger.com/profile/13544715040561543958noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-80079347603461746052008-09-22T17:37:00.000+01:002008-09-22T17:37:00.000+01:00Oh, and .NET has closures, making your argument ev...Oh, and .NET has closures, making your argument even more questionable.wekempfhttps://www.blogger.com/profile/05888776726588158230noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-22054847715778675402008-09-22T17:36:00.000+01:002008-09-22T17:36:00.000+01:00fsilber,Microsoft didn't "invent the names out of ...fsilber,<BR/><BR/>Microsoft didn't "invent the names out of thin air". They are names of concepts accepted by the industry. Java uses the same names (apart from delegate, where they have no equivalent concept) in the same ways. There's very little difference in the language "adding a delegate to an event" (.NET) and "adding a listener to an event" (Java). I think you're trying too hard to find criticism.wekempfhttps://www.blogger.com/profile/05888776726588158230noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-25079907265032485062008-09-22T17:32:00.000+01:002008-09-22T17:32:00.000+01:00Tarelli,We'll have to agree to disagree. Delegate...Tarelli,<BR/><BR/>We'll have to agree to disagree. Delegates are not simple syntactic sugar, nor something that a fancy IDE could render pointless. It fits every criteria you claim for synchronize (and I assume monitors). Sorry, you've supplied NO technical basis for your opinion, and so it's nothing more than your preference (nothing wrong with that, so long as you don't try to imply there is a technical reason behind said opinion).<BR/><BR/>The Java creators have a technical reason behind not having delegates in the language. It's not one I agree with, but at least there we can debate the topic on technical merits.wekempfhttps://www.blogger.com/profile/05888776726588158230noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-21305149907357035342008-09-22T17:29:00.000+01:002008-09-22T17:29:00.000+01:00P.S. I meant to say "easy-to-construct single-met...P.S. I meant to say "easy-to-construct single-method anonymous _inner_ classes" -- not "sub-classes".Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-14003990576366327112008-09-22T17:26:00.000+01:002008-09-22T17:26:00.000+01:00Delegates are a good approach (especially when usi...Delegates are a good approach (especially when using an IDE builder), but Microsoft's terminology and pedagogy suck (as usual). Terms are overloaded in metaphor-breaking ways.<BR/><BR/>Is an event something that happens, or is an event object a piece of fuctionality that gets executed _when_ something happens? Does the phrase "adding a delegate to an event" even make sense outside the limited world of Microsoft programming? No, it's nonsense -- it's as if President Bush in a speech told us that he is adding Condoleeza Rice (the delegate) to an earthquake (the event). This makes learning difficult for anyone who wants to understand at a level deeper than "monkey-see-monkey-do" (i.e., having to keep code samples on hand to remind you what is needed).<BR/><BR/>What we _should_ have is a language that provides closures (i.e., easy-to-construct single-method anonymous subclasses) as such, and event-handlers that are described as containers for closures -- to be called when the event of interest occurs.<BR/><BR/>"Add the delegate to the event" indeed!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-49828689245875689462008-09-22T16:16:00.000+01:002008-09-22T16:16:00.000+01:00Wekempf, it's not a tired mantra. We all want to ...Wekempf, it's not a tired mantra. We all want to make things faster and we like when that is possible. A language has a syntax which is more or less complex. The tradeoff is complicating the syntax against make something faster and the debate is wheter you decide something is at the right level to do it or not. Synchronize is a keyword that you add to a method and gives incredible benefits, i.e. loads of things that you don't have to care about, so my thumb is up and your assumptions is wrong. In my opinion for delegates the benefits are not worth to justify them to be treaten as an exception. To make such functionality easier I'd prefere some function in the tool that adds for you a listening mechanism such as when you generate getters/setters. That's my taste for things.Tarellihttps://www.blogger.com/profile/05276527371988960094noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-74560055725763006332008-09-22T16:14:00.000+01:002008-09-22T16:14:00.000+01:00Thanks for your comments I appreciate your explain...Thanks for your comments I appreciate your explainations! that's one of the reasons I'm happy that Giovacchia started this blog (I mean sharing knwoledge)...I hope there will be more and more people in the future willing to add some helpfull tips on my posts (that means a lot of people will have read it :D )Enrico Murruhttps://www.blogger.com/profile/13544715040561543958noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-42625306135600646522008-09-22T16:07:00.000+01:002008-09-22T16:07:00.000+01:00Scuffia,I wasn't trying to debate you, only trying...Scuffia,<BR/><BR/>I wasn't trying to debate you, only trying to supply you with some more knowledge about the topic.<BR/><BR/>I'm very sure you've used delegates already in a context where they are not simply function pointers. If you've added an event handler to a method on an object instead of just to a static method, you've already gone beyond simple function pointers. Seeing as how that's the most typical way to do things... I'll bet you've done it. :) Like I said, you're typical delegate is a bundling of a function pointer and an object pointer. This is an important distinction to make, because adding an event handler to a member function will create a reference to the object, and is a common cause of "memory leaks".wekempfhttps://www.blogger.com/profile/05888776726588158230noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-43345521278624477722008-09-22T15:49:00.000+01:002008-09-22T15:49:00.000+01:00Dear Wekempf I have no arguments to debate...as I ...Dear Wekempf I have no arguments to debate...as I said I have a long long jorney to the .NET understanding and surely I have a small idea of all things that are involved with the things I have written down...anyway this post was a kind of starting point of view about event Handling.<BR/>You are right that delegates have not to carry only 2 parameters (but is suggested); anyway in my poor experience it seems that as far as concerns event handling, delegates are method pointers, but that's all I can say (I haven't seen any other use yet!).<BR/>Moreover I disagree with Tarelli because the delegate/event paradigm can save you a bit of time and make more readable your code, as Event Handling is a common paradigm in current programming.<BR/>Fuck hell yes :DEnrico Murruhttps://www.blogger.com/profile/13544715040561543958noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-74493028078557814622008-09-22T14:06:00.000+01:002008-09-22T14:06:00.000+01:001. Delegates/events are not limited to the (objec...1. Delegates/events are not limited to the (object, EventArgs) parameters. That's only a convention. You can have delegates/events that take any arbitrary parameters. Mind you, I'm not recommending you do this, just don't assume you are limited.<BR/><BR/>2. A delegate isn't just a "function pointer". For starters, there's MulticastDelegate. Then there's the fact that a delegate packages both the "function pointer" and the "target object" into a single concept.<BR/><BR/>3. Anonymous delegates and lambdas combined with closures are something else you need to come to grips with. These concepts provide a lot more power than you have available to you in (the current) Java.<BR/><BR/>Tarelli, that's a tired mantra. If you REALLY feel that way, then I assume you take issue with Java's synchronized keyword, or even with the monitors built into that language. For that matter, I assume you prefer to code in assembly language. Delegates and events *ARE* "basic blocks that allow a C# developer to build any complex thing". Nothing is hidden from the developer with this language feature.wekempfhttps://www.blogger.com/profile/05888776726588158230noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-59265113175817853912008-09-22T12:11:00.000+01:002008-09-22T12:11:00.000+01:00Good old Tarelli sure is a fine chap, but he sure ...Good old Tarelli sure is a fine chap, but he sure likes to piss on good old Scuffia's flowers.Anonymoushttps://www.blogger.com/profile/13431481971279629409noreply@blogger.comtag:blogger.com,1999:blog-3760169963830810897.post-7866786084456716142008-09-22T12:09:00.000+01:002008-09-22T12:09:00.000+01:00I've no experience with C# but I disagree with goo...I've no experience with C# but I disagree with good old Scuffia. I prefere to have some basic blocks that allow me to build any compelx thing more than having many different blocks (=exceptions=more things to learn) specialized. Following that idea C# could introduce new syntax to the language to create singletons if they feel like. Would you like more public singleton class MyClass{...} because the code is more concise? Fuck hell no.Tarellihttps://www.blogger.com/profile/05276527371988960094noreply@blogger.com