Saturday, July 30, 2005
"If you want to use a multicast delegate, then it makes little sense for the delegate to have a return value." and " If several delegates are combined, what value is returned? The answer is the return value of the last delegate to be called—and hence the last delegate to be combined. All other return values will be discarded."
I see this as further evidence that multicast delegates were an afterthought, and not a good one.
P.s. This article states what has become obvious to me, i.e., that events are hyped-up multicast delegates.
Friday, July 29, 2005
- find the registry entry: [HKEY_CURRENT_USER]\Software\Microsoft\VisualStudio\7.1\Text Editor
- add a string with the name "Guides" and the value "RGB(128,0,0) 90"
- restart VisualStudio
This instruction works for version 2003, but by editing a similar registry entry it should work for versions 2002 and 2005 as well. The above gives a red line at column 90.
Tuesday, July 26, 2005
I came across the following gem by Martin Fowler:
"One of the most important things to document is the design alternatives you didn't take and why you didn't do them. That's often the most forgotten but most useful piece of external documentation you can provide." (UML Distilled, 3rd ed., p. 32)
Friday, July 22, 2005
Thursday, July 21, 2005
Another guess: In order to fix the problems that arose when using multicast delegates to do publish/subscribe, events were introduced (see a previous post). This is obviously just a band-aid, as can be clearly seen by the event declaration syntax: Instead of the normal declaration syntax: "(access) (type) (variable)", you have "(access) (event) (type) (variable)"!!
I think that multicast delegates and events both break the the norm, and I cannot figure why I have not seen more outbursts over this terrible language design stink; it has troubled me for some time now :(
- The "delegate" keyword is a reference type ("class" and "interface" are also reference types).
- The "event" keyword is a modifier (such as "public", "private", etc.), used exclusively with a delegate.
- All delegates are multicast.
- It is possible to use both delegates and events to implement the publish/subscribe mechanism in the Observer pattern, there are differences however.
- Events cannot be fired outside the class they are defined in (delegates can), i.e. MyEvent("message") is only possible within the class MyEvent is defined.
- Delegates can only be attached to events through += and detached through -=, e.g. MyEvent += new MyDelegate(Update).
- Delegates can, additionally, be attached to delegates through =, but this discards those delegates that have already been added.
The Observer pattern, as defined by the Gang-Of-Four (GOF), is actually different from the publish/subscribe mechanism using delegates. The GOF pattern uses ConcreteSubject and ConcreteObserver that implement the Subject and Observer interfaces, respectively.
Why have I not seen this simple explanation of the event keyword elsewhere? Hopefully this post will save someone else the trouble of making some sense out of it.
"Language comparisons are rarely meaningful and even less often fair. A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness." (p.5 in The Design and Evolution of C++)
"When class means user-defined type in C++, why didn't I call it type? I chose class primarily because I dislike inventing new terminology and found Simula's quite adequate in most cases." (p. 31)
I would have liked "type" better :)
Tuesday, July 19, 2005
-=operators applied to them." (from an article by Eric Gunnarson). So simple, yet I have not seen this stated anywhere ... and I have looked in many places!
Monday, July 18, 2005
Tuesday, July 12, 2005
- "I firmly believe that language design isn't an exercise in pure thought, but a very practical exercise in balancing needs, ideals, techniques, and constraints. A good language is not merely designed, it is grown. The exercise has more to do with engineering, sociology, and philosophy than with mathematics." (p. 104)
- "the most fundamental reason for relying on statically checked interfaces was that I was - as I still am - firmly convinced that a program composed out of statically type-checked parts is more likely to faithfully express a well-thought-out design than a program relying on weakly-typed interfaces or dynamically-checked interfaces."
- "Object-oriented programming is programming using inheritance. Data abstraction is programming using user-defined types. With few exceptions, object-oriented programming can and ought to be a superset of data abstraction."
P.s. Ravi Sethi says in his Programming Languages: "The popular term object-oriented programming refers to a programming style that relies on the concepts of inheritance and data encapsulation." (p.206, 1989). I seem to have been right on the money (or perhaps I just retrieved this info, subconsciously, from my memory?)