Lambda the Ultimate

Only it sounds to me he got it backwards: Tools can help with unnecessary complexity. Inherent complexity requires insight...

No problem, I hear that Rational Insight (R) for Visual Studio will be released any day now.

For example, in just about every recent object-oriented language, you have the ability, with some restriction, of directly assigning to a field of an object: x.a = 1, where x is an object, a is a field ... direct assignment is a typical kind of little problem that takes up a completely new dimension as you start having tens of thousands, hundreds of thousands, or millions of lines of code; thousands or tens of thousands of classes; many people working on the project; the project undergoing many changes, many revisions, and ports to different platforms. This kind of thing, direct assignment of object fields, completely messes up the architecture. So it's a small problem that becomes a huge one.

I have no trouble accepting that some people don't like direct assignment. Meyer's rationale of his distaste for it, though, seems rather like fear and loathing. It's wrong because there are millions of lines of code, thousands of classes, many people working at the same time, many revisions, ports to other platforms! If you used direct assignment, you may as well not get out of bed.

The alternate to direct assignment, that being indirect assignment via procedural call, is touted as the better solution because of contracts. This I can accept -- to a point. But I find this sort of hand-wringing boring. Can't we talk about how outside assignment of any kind can be avoided? Wouldn't that be better design, or is that utterly impractical?

It is interesting to me also that Meyer steps right up to the line of saying that functional programming solves an important class of problems that object/imperative programming doesn't, but stops short. I wonder why that is? Certainly in my own experience, programming in Objective Caml is proving to be a huge eye-opener.

Back to Brooks.
"By accidental, I did not mean occurring by chance, nor misfortunate, but more nearly incidental, or appurtenant...

The part of software building I called essence is the mental crafting of the conceptual construct; the part I called accident is its implementation process."

Seem to remember his 2000 Turing Award Lecture covered this topic.

To use Meyer's notation, x.a = 1 would constitute outside assignment, but so also would x.set_a(1). Why design a class so that you must expose "a" at all?

In C#, x.a = 1 might well be routed through a "property set" procedure anyway - the syntax enables that, and "a" needn't correspond directly to any internal field of x.

I'm drawn back to Stroustrup's recent suggestion that one of the points of classes is to maintain invariance - which is very much Meyer's kind of thing, if I'm not mistaken. C# property get and set syntax provides a concise way of making sure that accessors/mutators preserve invariance whilst making it look as if you're simply assigning to a field on a struct. Is this a bad thing?

Why design a class so that you must expose "a" at all?
It is a bit puzzling ;-)
Smalltalk instance variables cannot be public, and there isn't a strong convention to publish state accessor methods - rather the contrary.
On-the-other-hand Smalltalk does provide backdoor instVarAt: and instVarAt:Put: methods that directly access the instance variables, for system programming.

In Microsoft's component model, especially in the case of ActiveX controls used as GUI elements, a component object will have various "properties" that can be read, written and persisted outside of the object, for instance in a configuration file. A GUI form can be described declaratively by stating which classes of component are to be instantiated within the control container (the form itself) and what values are to be assigned to their properties.

Properties need not correspond directly to internal fields of objects, although sometimes they do. Many of their values may not change during the lifetime of the object; for instance the position, height, width and caption of a "command button". However, when these components are being laid out using the Visual Studio IDE's form designer, it is convenient for the IDE to be able to manipulate the properties of an already instantiated component, for instance when the user decides to resize a GUI element or change its colour.

Java "bean" components work in a similar way, IIRC - the idea is that an IDE can enumerate the properties of a bean using reflection, and expose them to the user for modification using the IDE's design tools. This applies to "enterprise" components in the EJB model as well as GUI elements.

The semantics of components like these are meant to serve the goals of "rapid" (or even "visual") development, but also to fit within a "component architecture" that provides, in theory at least, for encapsulation and re-use of functionality - two features that large-scale systems are alleged to benefit from. Meyer's criticism of methods that provide access to state seems to be that they encourage complex coupling between elements of a system; if so, this would presumably apply to "component architectures" in general. The more components you have, the more pieces of state are exposed and the more opportunities there are for one component's behaviour to be made dependent on another's state.

What this suggests to me is simply that the "component level" should not be the final level of encapsulation in a system: that groups and subgroups of components should themselves be hidden behind appropriate interfaces, and "backdoor" coupling between modules eliminated. Components are not the last word in modularity. But Meyer seems to be saying that they shouldn't be used at all, because of their potential to be used badly.

I don't see why direct assignment, or property-based configuration of components, shouldn't be permitted within the confines of a single module, provided that that module doesn't export its components' accessors for external use. (At a trivial level, this is the way I always used to work with VB6 forms: no code outside of the form module was permitted to access any of the properties of any of the controls in the form directly; rather, the form itself would have public methods to perform the desired functions. This is the difference between saying frmFoo.StartTimer and saying frmFoo.Timer1.Enabled = True, for instance).

Are we defining properties or are we exposing state?
Some tools need unfiltered access to state. Yet using that unfiltered access throughout our application creates unwanted dependencies. Seems like we need separate interfaces.

Meyer's criticism of methods that provide access to state
He's saying little more than a component should provide properties that are not dependent on state representation - change the representation, preserve the existing property interface. Something you seem to agree with - you're just drawing the component boundary in a different place.

Nothing *needs* unfiltered access to state except the language runtime system. Any component model can work with interfaces rather than directly with state (isn't all state in Smalltalk private?).

Some objects and protocols are so simple that direct access to state is sufficient. The problem is that if this is implemented via direct access then, in some languages, future development is harmed because you cannot intercept that processing if you want to modify behaviour later (afaik, in contrast, Python will let you intercept such actions, so, presumably, would Lisp, since this is a metaobject protocol issue). (Note that modifying behaviour later need not mean introducing a complex mess of extra inter-dependencies, but rather restructruing to give cleaner code - the ability to add indirection is intrinsically neitehr good nor bad).

In other (more C++/Java specific) words, accessing state directly is equivalent to having setter and getter methods that are public and final/non-virtual. No additional indirection is possible - that, and not the state itself, is the crux of the problem.

It's actually much worse... With "public final" accessors, it's at least still possible to modify the behavior or add inderection at the point where they're originally defined. It's also, of course, quite easy to make them non-final, if that's what's needed.

But with direct access, to modify the behavior in any way or add any kind of indirection one must search and modify an arbitrarily large amount of code.

Consider a simple example: suppose I have a class A with a field x, and I decide I'd really like to see a log message every time x is modified, for any reason. If I have a public final setX(...), this is no problem. But if x itself is public, I'm in big trouble.

For this reason, I strongly support the "all fields must be private" style for Java (haven't done enough C++ programming to know whether it translates). I get a dark feeling anytime I'm reading through code and I see direct access, especially if it's code I'm supposed to work on...

<loving-anamorphisms>

Class foo
   Public a As Integer
End Class


...


x = New Foo()
x.a = 1

Later, changing my mind:

Class foo
   Protected _a As Integer
   Public Property a() As Integer
      Get
         Return _a
      End Get
      Set(value As Integer)
         _a = value
      End Set
   End Property
End Class


...


x = new Foo()
x.a = 1

</loving-anamorphisms>

Doesn't work with inheritance, though - if I inherit from a base Foo with a public member, the subclasses cannot then restrict access to that member.

Class foo
Protected _a As Float

Problem is, though, getter & setters still have the effect of externalizing the values used for state. Taking something like:

b.setValue(10.0);

You've still got an external class that has to understand what the value of 10.0 means to the target class. Are these dollars? radians? etc... You may be able to manipulate within the class that it's not stored as single floating point value, but you've still got code out there that has a dependency on what the value of the state means.

Ah yes, you're right. Also, looks like I should have added Eiffel to the list with Python and Lisp (thanks Isaac).

In this second installment, Meyer discusses Design by Contract and the limits of formal languages for expressing contracts.

When I first thought about DbC I spent a lot of time trying to find a good formal language for contracts. In the end, I admit, I followed Meyer and simply use the programming language's boolean expressions coupled with the "old" keyword. But I am sure this is not the ultimate solution.