The Artima Developer Community
Sponsored Link

Delegates, Components, and Simplexity
A Conversation with Anders Hejlsberg, Part III
by Bill Venners with Bruce Eckel
September 1, 2003

<<  Page 3 of 3


Components are First-Class

Bill Venners: In an interview published on the O'Reilly Network, you justified C#'s support for properties and events by saying, "Developers are building software components these days. They are not building monolithic applications or monolithic class libraries. Everybody is building components that inherit from some base component provided by some hosting environment. These components override some methods and properties, and they handle some events, and put the components back in. It's key to have those concepts be first class."

I want to understand better what you mean by that, because I tend to think of myself as building classes, not components. Are you talking about people who are building components for other people to connect together in a Delphi, Visual Basic, or JavaBeans way? Is that what you mean by component?

Anders Hejlsberg: The great thing about the word component is that you can just sling it about, and it sounds great, but we all think about it differently. In the simplest form, by component I just mean a class plus stuff. A component is a self-contained unit of software that isn't just code and data. It is a class that exposes itself through properties, methods, and events. It is a class that has additional attributes associated with it, in the form of metadata or naming patterns or whatever. The attributes provide dynamic additional information about how the component slots into a particular hosting environment, how it persists itself—all these additional things you want to say with metadata. The metadata enables IDEs to intelligently reason about what a component does and show you its documentation. A component wraps all of that up.

Bill Venners: What I think of when I'm using Java is that I'm designing class libraries, not component libraries, and maybe that is because get and set is clunky. I do use get and set, and I certainly fire events, but I don't intend for these classes to be used in a Bean builder IDE. I am imagining that they'll be used by people who write code. So I'm still left wondering how many people are actually writing JavaBean-like components, and if that's the trend, because I don't see it much in my own experience.

Anders Hejlsberg: The object-oriented programming languages in mainstream use today are all hybrids. They have a lot of structured programming in them. And objects are still in many ways just structs with a bunch of methods and a this pointer. I think that conceptually, when you think of an object or a component, they do have properties and they do have events. And giving first class treatment to those things in the programming language makes that easier.

People will argue that C#'s support for properties and events is just syntactic sugar, but it's all just syntactic sugar, right? Heck, objects are just syntactic sugar. We could just all roll our own VTBLs, which you could do with C macros, right? Sure, you could write object-oriented programs in C. It's just a hell of a lot more complicated. And likewise, you can write components in C++ or Java, but because the core concepts are not first class in those programming languages, you end up having to squint more. There's that word again. With properties, they're not really properties, they're a getBla and a setBla. But when they show up in a property inspector, they're a bla. And you just have to know that mapping is there.

It is clear that components are a trend. It is the way we are all using our classes, but in most of the languages in which we deal with components, they are not first class concepts. And I'm just saying that they should be. We have been talking about the PME programming model—properties, methods, and events—for a long time now, and we've all used that in our day-to-day programming. Why don't we actually give it first class treatment in the programming language?

Next Week

Come back Monday, September 8 for part VIII of a conversation with Elliotte Rusty Harold about the design of the XOM API. I am now staggering the publication of several interviews at once, to give the reader variety. The next installment of this interview with Anders Hejlsberg will appear on Monday, September 15. If you'd like to receive a brief weekly email announcing new articles at, please subscribe to the Artima Newsletter.

Talk Back!

Have an opinion about the design principles presented in this article? Discuss this article in the News & Ideas Forum topic, Delegates, Components, and Simplexity.


Deep Inside C#: An Interview with Microsoft Chief Architect Anders Hejlsberg:

A Comparative Overview of C#:

Microsoft Visual C#:

Anders Hejlsberg was not the first Artima interviewee to mention taste. Jim Waldo made almost an identical comment about building a team of tasteful programmers in his interview:

And an entire portion of Ken Arnold's interview was devoted to design taste - Taste and Aesthetics:

<<  Page 3 of 3

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use