Re: Resolved: NOT (w/ informal proof). --Was Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming:OOP and memory management
From: Thomas Gagne (tgagne_at_wide-open-west.com)
Date: Wed, 25 Aug 2004 09:19:59 -0400
> "Dmitry A. Kazakov" wrote:
> Right. And the point of my argument is that it is *incorrect*
> (as in 'unnecessarily limited') to claim that sending a message
> to an object is a-priori an error whenever the receiving object
> does not have a statically bound method implementing that message.
> Dmitri sendMeTwentyBucksAsPenance.
> Now - do you have an implementation of such a method?
> No. But you could still accomplish the task, right?
> ( You won't of course. But the point is, you *could*.
> You could intercept the method call, and replace
> it with something that would achieve the intended result.
> In this hypothetical case, one presumes you would
> construct the replacement solution "dynamically",
> and then activate it. But one could imagine another
> scenario - in which you knew I would be sending
> a message, but did not know what I would name it.
> You might implement a method>>doesNotUnderstand: aMessage
> in which you accomplish what you know I will intend,
> and when I actually do send the above message,
> your DNU method sends me twenty bucks.
Thank goodess SQL isn't statically compiled. There's no way of telling ahead
of time what columns might be in the tuple until the SQL is written. It's
only at runtime that it can be determined whether the column names the
programmer referenced exist. And no one has a problem with that.
Along that line of thinking, I've an object called SybaseTuple that I use for
all rows coming back from the database. Rather than implement a get()/set()
methods (which don't read well IMO) it catches DNU exceptions and looks at its
list of column names to see if the selector matches. If it does it returns
For instance, given a row from the database with a column called contractKey I
Transcript show: aRow contractKey
Transcript show: (aRow get: 'contractKey')
or translated into Algolese:
There's measurably less syntax required in the 1st and 3rd examples than the
2nd and 4th.
So the type of SybaseTuple is dynamic because it can answer messages it
doesn't know about at compile time, and in an OO sending messages is more
natural and readable than sending messages with arguments. Imagine if the
same thing were required in SQL:
SELECT row.get('contractKey'), row.get('faceAmount'), row.get('..')
That's a whole lot of typing that introduces opportunity for typos, requires
more syntax, and increases the frequency of errors. Of course, when that's
the case (and it is in multiple languages) programmers create tools to
simplify the writing (coding assistants) to match-up the parenthesis, make
sure we only use functions "row" understands, put periods in the right spots,
and only pass it arguments it can accept, and we feel "it's a good thing".
Of course, both approaches are fragile when the tables/views change behind the
scenes and faceAmount is nolonger inside contract. A good browser will alert
us to the dependents of contract.faceAmount.
> No, just a different perspective than the one you're used to.
>>Contracts are imposed on *both* sides equally. You are trying to
>>treat bugs and errors as if they were same things.
> No, that isn't what I am trying to do.
> I am trying to describe "complete and total encapsulation",
> what you could infer from actually being that strict,
> and how applying the constraints of such inferences
> might result in something valuable.
Contracts, interfaces, type correctness, etc. are all forms of more closely
coupling modules together, creating dependencies not just on the messages and
arguments you can send, but on the types. It was always my understaning that
good OO designs sought minimum coupling.