Saturday, July 30, 2005

A Design Smell, cont.

I blogged recently about a bad smell from event. I found further evidence for the stink in a MSDN article I recently read, it says:

"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

Hidden feature of VisualStudio

I came across a blog entry regarding a hidden feature of VisualStudio (I cannot find the entry again). By adding a registry entry it is possible to let VisualStudio display vertical lines in the code viewer. This is a useful reminder to limit the number of characters per line (so that the print-out become more legible). You can try it out following the instructions below:
  • 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

Documenting Design

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

Console text color in .NET

I found an article explaining how to change the text-color in the Console. Useful, e.g., when many threads write to the same window.

Thursday, July 21, 2005

A Design Smell

I think there is a serious shitsmell (ISL. sk√≠­talykt) to how delegates and events are used to support the publish/subscribe mechanism. I think delegates are fine, but my guess is that someone had the "brilliant" idea of using them to implement the publish/subscribe mechanism as well, and this was done by making all delegates multicast. So now the delegate is actually a container of delegates and you can start adding delegates to delegates, certainly not in accordance with the normal use of other types. Sometimes you will be using delegate-the-container and sometimes you will be using delegate-the-function-pointer, this can be confusing.

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 :(

Events and delegates in C#, cont.

This is a continuation of a previous post.

  • 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.
The differences in using delegates and events in implementing publish/subscribe are the following:
  • 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.
Conclusion: applying the "event" modifier to a delegate restricts its use and makes programming with them more safe. This is enforced at compile-time.

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.

Comparing programming languages

I think that Stroustrup's comment on comparing programming languages gives the rest of us a welcomed rest from trying to do so :)

"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++)

"class" vs. "type"

An interesting quote from Stroustrup's 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

Events and delegates in C#

It has been a source of great frustration that I could not figure out why the event keyword was necessary. To me it looked like you could just drop it, and in fact this is true. The "only" (I am told there are also some finer differences) difference between a delegate and an event is that "events are like delegates that can only have the += and -= 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

Reference/Value type/parameter, cont.

I have blogged previously about how objects are passed in C#. I sometimes forget that this is done differently in Java, in Java in a Nutshell it says: "Java manipulates objects 'by reference,' but it passes object references to methods 'by value.'"

Tuesday, July 12, 2005

Quotes from "The Design and Evolution of C++"

A quote from "The Design and Evolution of C++" which I thought was enlightening:
  • "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)
A different quote, which I also found interesting, even though I have not completely formed my own opinion on it, is:
  • "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 defined, cont.

In a previous post I tried to define "object oriented", I am currently reading the opening chapters of Bjarne Stroustrup's "The Design and Evolution of C++", there he quotes himself saying:
  • "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."
I have to admit that I patted myself on the back reading that quote :)

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?)