Lambda the Ultimate

procedure x13 is


   type t1 is record x:integer; end record;
   type t2 is record x:t1; end record;
   type t3 is record x:t2; end record;
   
   v:t3;
   x:integer renames v.x.x.x;
   
begin
   v.x.x.x:=5;
   x:=10;
end;   

Compare

document.all.someElement.style.color = 'red'; (JavaScript)

ActiveWorkbook.Sheets("Report").Cells(2, 4).NumberFormat = "@" ' Excel VBA

Document applyStyleAttribute: red toStyle: color ofElement: someElement

ActiveWorkbook applyNumberFormat: "@" toCell: 2@4 inSheet: "report"

The sort-of-Smalltalk code adheres to the "Law of Demeter": instead of drilling down through a series of collections via the dot syntax, a top-level method provides access to the functionality of objects further along the chain with actually exposing the objects themselves. Smalltalk's syntax makes this kind of coding look cleaner than the VBA/Javascript approach.

I use With a lot in VB coding, because VB makes it easy to string chains of methods together via the dot syntax and painful to do so repeatedly. A lot of the libraries (Excel VBA being a case in point) are designed with the assumption that this is the way you will access objects at a low level of granularity (inner containers of inner containers, or subdivisions of subdivisions), given an object representing an initial context. But the problem With addresses - the verbosity and (potential, depending on how smart your compiler is) inefficiency of repeatedly passing requests along a chain of methods - is a side-effect of this approach, which Demeter-ish Smalltalk syntax effectively removes.

class Foo {
  Foo setColour(Colour c) {c_ = c; return this;}
  Foo setSize(int i) {i_ = i; return this;}
  Foo setBar(Bar b) {b_ = b; return this;}
}


myFoo.setColour(red)
     .setSize(20)
     .setBar(baz);

colour: aColour
   colour := aColour


size: aNumber
   size := aNumber


myFoo colour: #red; size: 20.

windows.get(TOP).controls[12].canvas.moveto(10,20);

Such chaining is very common in object hierarchies such as a browser (DHTML) or XML DOM. In this context the objects are tightly coupled as their position in the hierarchy is usually a part of their definition. Also, such objects are unlikely to appear outside that context.

I do find, however, that explicitly specifying such long chains is an indication to the brittleness of the code accessing the DOM. I prefer to navigate to the target object and operate there.

Oh, by the way, we got to discussing this issue while talking about MS Scripting Host

The issue you mention is certainly valid to my mind, especially in the context of .NET

Sure, but still...

To an SQL guru everything looks like a database table, to to OOP programmers everything looks like class hierarchy. But that's just our paradigms talking ("if all you got is a hammer...")

Of course, if we are programming in an OOP language it is natural (and logical) to design APIs that work this way. What worries me is that this lead to lock-in and people tend to forget that other designs are also possible.

This seems to have been one of the things that bothered Richard Gabriel: Objects Have Failed: Discursive Notes

9. People enthused by objects hogged the road, would not get out of the way, would not allow alternatives to be explored—not through malice but through exuberance—and now resources that could be used to move ahead are drying up. But sometimes this exuberance was out-and-out lying to push others out of the way.

Dan Shappir wrote:

Isn't such chaining an indication that the objects are somehow tightly coupled. Isn't there some law or principle of encapsulation that's being broken?

The Law of Demeter (don't call methods on objects returned by methods on other objects, or "only talk to your immediate friends") may be; but it's open to question whether that really pertains to encapsulation per se: each object in the chain is exposed via the public interface of another object, after all. The point of the Law of Demeter is to reduce coupling, and to avoid situations where a change in one class's interface has to be propagated not only to that class's clients but to its clients' clients, and so on.

Ehud Lamm wrote:

To an SQL guru everything looks like a database table, to to OOP programmers everything looks like class hierarchy. But that's just our paradigms talking ("if all you got is a hammer...")

I did some work this week building some convenience classes for XML-based REST applications - classes for use by an ASP author to retrieve an XML document sent via HTTP POST, for instance. What motivated me to do this, instead of just using the MS-supplied SOAP Toolkit and binding web service invocations straight into methods on COM objects, was the realisation that SOAP used for RMI is a way of making everything look like a method invocation. The disguise isn't altogether convincing. For one thing, the object created to service the method call is discarded as soon as the method returns, so it isn't even the same as accessing a remote component via DCOM. For another thing, the mappings between parameter types and XSD schema types are automatic only for a range of simple types, after which you have to write your own custom handlers anyway. It struck me that what I wanted from web services was resources that could be accessed by any client that could send and receive XML to and from a URL, not a verbose and crippled version of DCOM/CORBA. The MS SOAP toolkit actually makes creating and accessing web services tolerably straightforward, but it does also tend to lock you into to an object/component way of looking at the domain rather than (for instance) a resource/state transfer approach.

This is pretty interesting. Might be worth a front page topic thread.

introduced "With" to VBA
From Modula2 to Oberon, this kind of WITH statement was removed!
(Although one suspects that was partly so the keyword could be given a different purpose.)

Looking back over the development of that Pascal, Modula, Oberon2 family of languages, it's striking how much experimentation has been aimed at removing features from the language. (The FOR loop was removed in Oberon, and snuck-back 3 years later into Oberon2.)