dynamic type checking - a pauline conversion?

6 views
Skip to first unread message

Robert C. Martin

unread,
Mar 9, 2004, 7:40:19 PM3/9/04
to
> From: Isaac Gouy [private email]
> To: Uncle Bob.
>
> My impression is that your opinion on the relative benefits of dynamic
> and static type checking, has changed over the years.
>
> Have you written about the circumstances which led you to think
> differently?

Yes, I wrote this up in a blog on artima:

http://www.artima.com/weblogs/viewpost.jsp?thread=4639

I've been a statically typed bigot for quite a few years. I learned my
lesson the hard way while using C. Too many systems crashed in the
field due to silly typing errors. When C++ came out, I was an avid
adopter, and rabid enforcer of strong typing. I scoffed at the
smalltalkers who whined about the loss of flexibility. Safety, after
all, was far more important than flexibility -- and besides, we can
keep our software flexible AND statically typed, if we just follow
good dependency management principles.

Four years ago I got involved with Extreme Programming. I liked the
pragmatic emphasis it placed upon developing software. I also liked
the emphasis it put on testing. Since then I have become test
infected. I can no longer conceive of writing software without using
test driven development. I can't imagine not having a comprehensive
suite of unit tests to back up my development.

About two years ago I noticed something. I was depending less and less
on the type system for safety. My unit tests were preventing me from
making type errors. The more I depended upon the unit tests, the less
I depended upon the type safety of Java or C++ (my languages of
choice).

I thought an experiment was in order. So I tried writing some
applications in Python, and then Ruby (well known dynamically typed
languages). I was not entirely surprised when I found that type issues
simply never arose. My unit tests kept my code on the straight and
narrow. I simply didn't need the static type checking that I had
depended upon for so many years.

I also realized that the flexibility of dynamically typed languages
makes writing code significantly easier. Modules are easier to write,
and easier to change. There are no build time issues at all. Life in a
dynamically typed world is fundamentally simpler.

Now I am back programming in Java because the projects I'm working on
call for it. But I can't deny that I feel the tug of the dynamically
typed languages. I wish I was programming in Ruby or Python, or even
Smalltalk.

Does anybody else feel like this? As more and more people adopt test
driven development (something I consider to be inevitable) will they
feel the same way I do. Will we all be programming in a dynamically
typed language in 2010?


JXStern

unread,
Mar 9, 2004, 8:43:32 PM3/9/04
to
On Tue, 09 Mar 2004 18:40:19 -0600, Robert C. Martin
<uncl...@objectmentor.com> wrote:
>About two years ago I noticed something. I was depending less and less
>on the type system for safety. My unit tests were preventing me from
>making type errors. The more I depended upon the unit tests, the less
>I depended upon the type safety of Java or C++ (my languages of
>choice).

Ha!

Try unit-testing Petzold-style message-loop Windows 2.x programs
(circa 1987), where an hdc/hwnd error hangs the machine.

>Does anybody else feel like this? As more and more people adopt test
>driven development (something I consider to be inevitable) will they
>feel the same way I do. Will we all be programming in a dynamically
>typed language in 2010?

You say the issue never even comes up when you use Python and Ruby, so
what does TDD have to do with it?

Soft/dynamic/variable-typed languages have their benefits, one may
even say they are sort of the same benefits that XP advocates seem to
like - freedom. That is not to say *untyped*, but modern languages
have all sorts of enums and objects and whatnot that carry constraints
and type info at the syntactic level. Given that, the need for
compile-time checking is somewhat more redundant than in early days.
Also, given more robust OS support for error-handling!

Joshua Stern

Daniel T.

unread,
Mar 9, 2004, 11:48:29 PM3/9/04
to
Robert C. Martin <uncl...@objectmentor.com> wrote:

> Does anybody else feel like this? As more and more people adopt test
> driven development (something I consider to be inevitable) will they
> feel the same way I do. Will we all be programming in a dynamically
> typed language in 2010?

I love creating systems using dynamic typed languages, I hate having to
decipher a system that was built using a dynamic typed language. Take a
large scale program written in a dynamic typed language and see how long
it takes to make a list of all the types that can be used in a
particular variable, then do the same with a static typed language. The
former job can be a day long undertaking at times, the latter is so
simple, there are tools that can do it automatically...

Maybe it's stupid of me to want to know this information in the first
place...

[client]<>--->[AbstractConcept]
A
|
+--+--+
| |
[A] [B]


In C++ the above might look something like:

class AbstractConcept { };

class Client {
AbstractConcept* as;
};

class A: public AbstractConcept { };
class B: public AbstractConcept { };


In Python:

class Client:
def __init__(self):
self.abstractConcept = #whatever

class A:
pass

class B:
pass

Notice that in the Python code, the abstract concept is almost
completely absent (it's demoted to the name of the object.) And the only
way we can determine the properties of the abstract concept is to
examine all uses of the object in Client (and all clients that Client
might expose its variable to,) there is no central repository even
outlining the methods this particular abstract concept must be able to
support.

All three classes (Client, A and B) depend on this abstract concept, but
in dynamic typed languages, the concept exists solely in the minds of
the programmers. There is no embodiment of this concept in the code
itself.

To me the type safety exists simply because more information is being
fed to the compiler, information that the compiler can use to make
certain assumptions. Information that fellow programmers can use to
understand the concepts being used by the designers of the system.

Or to put it another way, I often write OO examples in a static typed
language (rather than a dynamic typed one) simply because more
information is exposed in the example when using such languages.

Universe

unread,
Mar 9, 2004, 11:56:25 PM3/9/04
to
"Robert C. Martin" <uncl...@objectmentor.com> wrote in message
news:cmos401b4aa3lu33q...@4ax.com...

Static typing would tend to enforce a rational object model, more oriented
toward initial up-front analysis, it seems.

I like Dynamic OOPLs, however it appears XP'ers use them to facilitate
a little hack here, another hack there, etc and so forth.

Elliott


Ron Jeffries

unread,
Mar 10, 2004, 6:46:35 AM3/10/04
to
On Tue, 9 Mar 2004 23:56:25 -0500, "Universe" <univ...@tAkEcovadOuT.net> wrote:

>Static typing would tend to enforce a rational object model, more oriented
>toward initial up-front analysis, it seems.

Partly yes, partly no. Static typing constrains, often severely, what one can
do, or the difficulty of doing it. This places a higher value on up-front
consideration, to avoid dead ends.

However, because of the artificial constraints often imposed, static typing can
also force one to a design which is less natural, less rational, than one would
use in a more dynamic language.

In all, I prefer the dynamic side. Although I came to dynamic typing after
static, and had fears that the freedom would lead to bad designs and unreliable
code, that turned out not to be the case. The result, for me, was simpler
programs, better designs, higher productivity.


>
>I like Dynamic OOPLs, however it appears XP'ers use them to facilitate
>a little hack here, another hack there, etc and so forth.

I always forget the technical terms. Is this slander, libel, or just lies?

Regards,

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

Daniel T.

unread,
Mar 10, 2004, 7:53:45 AM3/10/04
to
Ron Jeffries <ronje...@REMOVEacm.org> wrote:

> On Tue, 9 Mar 2004 23:56:25 -0500, "Universe" <univ...@tAkEcovadOuT.net>
> wrote:
>
> >Static typing would tend to enforce a rational object model, more oriented
> >toward initial up-front analysis, it seems.
>
> Partly yes, partly no. Static typing constrains, often severely, what one can
> do, or the difficulty of doing it. This places a higher value on up-front
> consideration, to avoid dead ends.
>
> However, because of the artificial constraints often imposed, static typing
> can
> also force one to a design which is less natural, less rational, than one
> would
> use in a more dynamic language.

What constraints are you talking about? I know of no constraints imposed
by static typed languages that don't also exist (implicitly) in dyanamic
typed languages.

Peter Hermann

unread,
Mar 10, 2004, 7:55:33 AM3/10/04
to
Robert C. Martin <uncl...@objectmentor.com> wrote:
> Does anybody else feel like this?

no

> Will we all be programming in a dynamically
> typed language in 2010?

Robert,
I know you since more than one decade as a strongheaded Ada ignorer.
Nevertheless I read your whole contribution and again shook my head.
All your needs are fulfilled by Ada, hands down.

Well, then, for the others:

http://www.csv.ica.uni-stuttgart.de/homes/ph/resources_on_ada.html


--
--Peter Hermann(49)0711-685-3611 fax3758 ica...@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Ilja Preuß

unread,
Mar 10, 2004, 8:49:32 AM3/10/04
to
Daniel T. wrote:

> What constraints are you talking about? I know of no constraints
> imposed
> by static typed languages that don't also exist (implicitly) in
> dyanamic typed languages.

We do have a utility method which does the following:

if (closable != null) closable.close();

In Java, you cannot write this method so that it supports InputStream,
OutputStream, Reader, Writer, Socket, ResultSet, Statement, Connection
etc. - just because there is no Closable interface (other than using
reflection, which is basically emulating the feature of dynamic type
checking).

Take care, Ilja


Ilja Preuß

unread,
Mar 10, 2004, 8:51:45 AM3/10/04
to
Peter Hermann wrote:

> Robert,
> I know you since more than one decade as a strongheaded Ada ignorer.
> Nevertheless I read your whole contribution and again shook my head.
> All your needs are fulfilled by Ada, hands down.

Interesting - how does Ada solve the Closable problem I explained in my
other post in this thread?

Curious, Ilja


James A. Robertson

unread,
Mar 10, 2004, 9:29:19 AM3/10/04
to
On Wed, 10 Mar 2004 01:43:32 GMT, JXStern <JXSternC...@gte.net>
wrote:

>On Tue, 09 Mar 2004 18:40:19 -0600, Robert C. Martin
><uncl...@objectmentor.com> wrote:
>>About two years ago I noticed something. I was depending less and less
>>on the type system for safety. My unit tests were preventing me from
>>making type errors. The more I depended upon the unit tests, the less
>>I depended upon the type safety of Java or C++ (my languages of
>>choice).
>
>Ha!
>
>Try unit-testing Petzold-style message-loop Windows 2.x programs
>(circa 1987), where an hdc/hwnd error hangs the machine.

Which would be relevant to anything today how?

>
>>Does anybody else feel like this? As more and more people adopt test
>>driven development (something I consider to be inevitable) will they
>>feel the same way I do. Will we all be programming in a dynamically
>>typed language in 2010?
>
>You say the issue never even comes up when you use Python and Ruby, so
>what does TDD have to do with it?
>
>Soft/dynamic/variable-typed languages have their benefits, one may
>even say they are sort of the same benefits that XP advocates seem to
>like - freedom. That is not to say *untyped*, but modern languages
>have all sorts of enums and objects and whatnot that carry constraints
>and type info at the syntactic level. Given that, the need for
>compile-time checking is somewhat more redundant than in early days.
>Also, given more robust OS support for error-handling!
>
>Joshua Stern

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

James A. Robertson

unread,
Mar 10, 2004, 9:32:36 AM3/10/04
to
On Wed, 10 Mar 2004 04:48:29 GMT, "Daniel T."
<postm...@eathlink.net> wrote:

>Robert C. Martin <uncl...@objectmentor.com> wrote:
>
>> Does anybody else feel like this? As more and more people adopt test
>> driven development (something I consider to be inevitable) will they
>> feel the same way I do. Will we all be programming in a dynamically
>> typed language in 2010?
>
>I love creating systems using dynamic typed languages, I hate having to
>decipher a system that was built using a dynamic typed language. Take a
>large scale program written in a dynamic typed language and see how long
>it takes to make a list of all the types that can be used in a
>particular variable, then do the same with a static typed language. The
>former job can be a day long undertaking at times, the latter is so
>simple, there are tools that can do it automatically...
>

I think that runs pretty much the opposite of my experience. I spent
many years doing C, and I've spent many years doing Smalltalk. I have
many recollections of being tossed in front of unfamiliar C code, and
being finding it extremely hard to follow. Oddly enough, having the
word 'int' in front of various variables didn't help a lot.

Smalltalk, on the other hand, is much, much easier to deal with that
way. I've been in front of many unfamiliar systems as a consultant,
and been able to figure out what they were up to pretty quickly.
IMHO, the presence of typing information neither helps nor hinders in
following unfamiliar code.

>Maybe it's stupid of me to want to know this information in the first
>place...
>

Maybe that information is just of no inherent value....

<Talk Small and Carry a Big Class Library>

Ilja Preuß

unread,
Mar 10, 2004, 10:12:05 AM3/10/04
to
James A. Robertson wrote:

>>> Does anybody else feel like this? As more and more people adopt test
>>> driven development (something I consider to be inevitable) will they
>>> feel the same way I do. Will we all be programming in a dynamically
>>> typed language in 2010?
>>
>> You say the issue never even comes up when you use Python and Ruby,
>> so what does TDD have to do with it?

"My unit tests kept my code on the straight and narrow", I'd guess.

Take care, Ilja


JXStern

unread,
Mar 10, 2004, 10:38:05 AM3/10/04
to
On Wed, 10 Mar 2004 09:29:19 -0500, James A. Robertson
<jar...@gosmalltalk.com> wrote:
>>Try unit-testing Petzold-style message-loop Windows 2.x programs
>>(circa 1987), where an hdc/hwnd error hangs the machine.
>
>Which would be relevant to anything today how?

It's a data point from a time when programming was done without types,
and people suffered from it. It seems to confirm RCM's initial
thought that there's a problem in there someplace, but suggests that
there's more to fixing it than doing TDD. It suggests that strong
typing available in C++ might be advisable, might prevent whole
classes of problems, in that old environment and in newer ones.

Have a nice day.

J.


thoff

unread,
Mar 10, 2004, 10:51:39 AM3/10/04
to

Robert C. Martin wrote:
> Does anybody else feel like this? As more and more people adopt test
> driven development (something I consider to be inevitable) will they
> feel the same way I do. Will we all be programming in a dynamically
> typed language in 2010?

You are saying a dynamically typed language is the best choice
for all circumstances? That i don't agree with.

Your choice is based on the assumption that people will write
unit tests and maintain them. That is simply not a justifiable
assumption in 95% of the people i have ever worked with. Even
those that do use TDD i have found the quality of the effort is
still very developer specific.

Given my assumption then i must use judgement as to what is
important in what situation. I know, we rather replace judgement
with simplistic rules, but i still think judgement is what
professionals with experience can bring to the game.

I use perl and no unit testing for even
very complicated web sites and that works well enough 99% of
the time because i find bugs are rare regardless of the methodology.
Few people work on the system. No problem. Unit testing in this
case is an uncessary burden.

On another system that is a C++ based in a very complex embedded
environment with a 100 developers of different abilities spaced
all over the country. A single mistake can cost millions. In this
environment i very glad for static type checking because i *know*
i can not rely on people writing and updating unit tests. The overhead
of defining abstract interfaces is very small in this scenario
given the payoff.

I find absolute rules, though they make good grist for discussion,
are not that useful because you must find a solution that meets
your requirements and your problem space. Assuming into existence
a group of engineers who write high quality unit tests and update
them 100% of the time is a very hard precondition.

Shayne Wissler

unread,
Mar 10, 2004, 11:20:38 AM3/10/04
to

"Robert C. Martin" <uncl...@objectmentor.com> wrote in message
news:cmos401b4aa3lu33q...@4ax.com...

> I've been a statically typed bigot for quite a few years. ...


> When C++ came out, I was an avid
> adopter, and rabid enforcer of strong typing.

...

> Four years ago I got involved with Extreme Programming.

...

> Since then I have become test
> infected. I can no longer conceive of writing software without using
> test driven development.

...

> Life in a dynamically typed world is fundamentally simpler.

...

> Does anybody else feel like this? As more and more people adopt test
> driven development (something I consider to be inevitable) will they
> feel the same way I do. Will we all be programming in a dynamically
> typed language in 2010?

No, I don't, and Bob, do you see the pattern the above? You seem to swing
from one Extreme to another. How about some moderation?

I think static typing has important uses. I also think dynamic techniques
have important uses. My ideal language has both features. Which lets me
decide what is appropriate based on the situation at hand (but in general I
would use static typing more often--there's no point in writing extra tests
for something that can be tested by the compiler, and a statically typed
program is more easily understood).


Shayne Wissler


Tsolak Petrosian

unread,
Mar 10, 2004, 11:51:18 AM3/10/04
to
Correct me if I am wrong. But Ruby, Python and Smalltalk are not truly
dynamic languages since "object" in those languages cannot dynamically
change its type.

Tsolak Petrosian

Ilja Preuß

unread,
Mar 10, 2004, 11:54:04 AM3/10/04
to

As the subject of this thread indicates, it's about dynamic *type checking*.
Ruby, Python and Smalltalk are dynamically typed languages (which means that
the type of an object is checked at runtime instead of compile time, as far
as I know).

Take care, Ilja


Thomas Gagné

unread,
Mar 10, 2004, 12:25:45 PM3/10/04
to
Hmm. I thought Smalltalk's #become: allowed an object to change its
types. Of course, using it is considered a design problem and strongly
discouraged, I think. I've had no use for it (yet).

Tsolak Petrosian wrote:

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

Dave Harris

unread,
Mar 10, 2004, 1:52:00 PM3/10/04
to
JXSternC...@gte.net (JXStern) wrote (abridged):

> >>Try unit-testing Petzold-style message-loop Windows 2.x programs
> >>(circa 1987), where an hdc/hwnd error hangs the machine.
> >
> >Which would be relevant to anything today how?
>
> It's a data point from a time when programming was done without types,
> and people suffered from it.

No-one is advocating programming without types. RCM is talking about
checking the types at run-time. If that were done by Windows 2.x, mixing
an HDC with an HWND would give a well-defined error rather than a machine
hang.

The Petzold-style message-loop may be hard to unit test; I don't know. If
it is, I'd say that was an argument for not using Petzold style.

-- Dave Harris, Nottingham, UK

JXStern

unread,
Mar 10, 2004, 2:03:35 PM3/10/04
to
On Wed, 10 Mar 2004 18:52 +0000 (GMT Standard Time),
bran...@cix.co.uk (Dave Harris) wrote:
>> >>Try unit-testing Petzold-style message-loop Windows 2.x programs
>> >>(circa 1987), where an hdc/hwnd error hangs the machine.
>> >
>> >Which would be relevant to anything today how?
>>
>> It's a data point from a time when programming was done without types,
>> and people suffered from it.
>
>No-one is advocating programming without types. RCM is talking about
>checking the types at run-time. If that were done by Windows 2.x, mixing
>an HDC with an HWND would give a well-defined error rather than a machine
>hang.

And I'm agreeing with RCM. If you put a typed value into a variant,
it's still checkable. It's all good.

But you couldn't do any of that, back in the day, and without it, TDD
wouldn't help, at least not nearly as much as static typing.

>The Petzold-style message-loop may be hard to unit test; I don't know. If
>it is, I'd say that was an argument for not using Petzold style.

Anything that locks up and costs you five minutes to reboot and
reestablish when you hit a bug is a major pain (and doing realtime
message parsing, you can't step through it effectively either).

Only the guys who write runtime libraries even know what a message
loop is anymore, VC/MFC and VB obsoleted Petzold-style programming by
about 1991 and nobody misses it in the least. How often do you even
have to make a raw API call anymore?

J.

Universe

unread,
Mar 10, 2004, 3:34:34 PM3/10/04
to

"Dave Harris" <bran...@cix.co.uk> wrote in message
news:memo.20040310185240.456A@brangdon.m...

A post<=>dispatch message loop is an integral part of the way the Windows OS
operates. I.E. the Petzold's message loop simply exposes what is happening
in the Windows kernel. The way the code for various Windows boxes
communicates is by posting to Windows and Windows then dispatches the
intended recipient code. Both the post and dispatch occur in a loop. This
happens even today with WinXP. The loop however has been "subsumed" within
the MFC, .NET, etc API's.

Elliott
--
Several powerful techniques are available to control the flow of information
to viewer,
including progressive disclosure, detail hiding, and layering and
separation.
As Massironi notes in his discussion about graphic images, "useful
drawings are not
exhaustive; they are selective".


Ron Jeffries

unread,
Mar 10, 2004, 4:43:43 PM3/10/04
to
On Wed, 10 Mar 2004 12:53:45 GMT, "Daniel T." <postm...@eathlink.net> wrote:

>> However, because of the artificial constraints often imposed, static typing
>> can
>> also force one to a design which is less natural, less rational, than one
>> would
>> use in a more dynamic language.
>
>What constraints are you talking about? I know of no constraints imposed
>by static typed languages that don't also exist (implicitly) in dyanamic
>typed languages.

I'm thinking largely of the constraints around needing to declare everything in
advance, which leads to tons of declared interfaces, and objects that want to
inherit from lots of them. Offhand, I can't think of anything I couldn't
program, but I find that the need to do all that declaration makes some
solutions harder to get to in practice, even though they are technically
possible.

Does that help to clarify? If not, inquire further ...

Ron Jeffries

unread,
Mar 10, 2004, 4:45:27 PM3/10/04
to

This reminds me of a related topic which isn't a property, strictly speaking, of
static vs dynamic, but that seems to come along with dynamic languages and much
more rarely with static. In the D languages I most like to use, everything
really is an object, and therefore everything is nullable. In the static
languages, some primitive types are not nullable.

you can always program around that ... but it's not what I'd call elegant.

Isaac Gouy

unread,
Mar 10, 2004, 6:02:47 PM3/10/04
to
"Daniel T." <postm...@eathlink.net> wrote in message news:<postmaster-90B88...@news6.west.earthlink.net>...

> Take a large scale program written in a dynamic typed language and see how
> long it takes to make a list of all the types that can be used in a
> particular variable, then do the same with a static typed language. The
> former job can be a day long undertaking at times, the latter is so
> simple, there are tools that can do it automatically...
> Maybe it's stupid of me to want to know this information in the first
> place...

That would depend on why you wanted to know ;-)

-snip_


> Notice that in the Python code, the abstract concept is almost
> completely absent

Hmmm is it impossible to define abstract classes in Python?

Smalltalk IDEs *generate* a verbose template for class definition; the
different class definitions shown in the IDE would be something like
this:

Smalltalk defineClass: #Client
superclass: #{Core.Object}
instanceVariableNames: 'abstractConcept'

Smalltalk defineClass: #AbstractConcept
superclass: #{Core.Object}

Smalltalk defineClass: #A
superclass: #{Smalltalk.AbstractConcept}

Smalltalk defineClass: #B
superclass: #{Smalltalk.AbstractConcept}


> All three classes (Client, A and B) depend on this abstract concept, but
> in dynamic typed languages, the concept exists solely in the minds of
> the programmers.

As we've seen we can also use abstract classes in a dynamically
checked language.

Daniel Parker

unread,
Mar 10, 2004, 6:51:05 PM3/10/04
to
"Ilja Preuß" <pre...@disy.net> wrote in message
news:c2n6hj$ov3$1...@stu1id2.ip.tesion.net...
I have to confess that I don't fully understand the Closable problem. What
problem do you solve when you have a generic method call close on an
arbitary object? Is this just to save yourself from writing a few lines of
code, or do you find yourself dealing with broad classes of system resources
in a generic manner? Would you handle errors and exceptions from calling
close on a file resource and a database resource in the same way?

Regards,
Daniel Parker


Isaac Gouy

unread,
Mar 10, 2004, 8:24:45 PM3/10/04
to
"Ilja Preuß" <pre...@disy.net> wrote in message news:<c2n6dd$ojr$1...@stu1id2.ip.tesion.net>...

> We do have a utility method which does the following:
>
> if (closable != null) closable.close();
>
> In Java, you cannot write this method so that it supports InputStream,
> OutputStream, Reader, Writer, Socket, ResultSet, Statement, Connection
> etc. - just because there is no Closable interface (other than using
> reflection, which is basically emulating the feature of dynamic type
> checking).

So there is no existing interface that includes the method 'close' and
is implemented by all of the types we wish to assign to the variable
'closeable'. The general solution is to define a new interface
ICloseable and redefine all of the types to implement ICloseable.

In Java (without AspectJ) the only way we can do that is by editing
the source code for all the class definitions (which wouldn't be a
great approach even if we had the source code).

In Nice, a statically checked language, (and other multimethod
languages) we can retroactively add a new interface to class
definitions. Here's one example:
http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/AspectOrientedMultiMethodExample

Daniel T.

unread,
Mar 10, 2004, 11:18:10 PM3/10/04
to
ig...@yahoo.com (Isaac Gouy) wrote:

But there is absolutely no requirement that a class inherit from
AbstractConcept in order to be used, or useful in the variable
'abstractConcept'. The AbstractConcept class literally does nothing in
the SmallTalk code, the only possible use of the class is a repository
for any shared implementation of the various subclasses, which could as
easily be placed in a delegate, or duplicated in the clients. Changes
can be made to the class "Client" that assume a change in the
AbstractConcept interface, and as long as classes A and B are modified
to suit, no change need be made to AbstractConcept itself, thus allowing
a drift between the class AbstractConcept, and the actual concept it is
supposed to represent.

All of this means that I cannot easily tell if an object of a particular
class is useful in the variable 'abstractConcept' unless I make a
detailed study of what messages are sent to 'abstractConcept'.

Please don't take this as a slam against dynamic typed languages, as I
said I like using them. I think they help a programer generate systems
faster than in static typed languages.

Daniel T.

unread,
Mar 10, 2004, 11:36:01 PM3/10/04
to
"Ilja Preuß" <pre...@disy.net> wrote:

> Daniel T. wrote:
>
> > What constraints are you talking about? I know of no constraints
> > imposed
> > by static typed languages that don't also exist (implicitly) in
> > dyanamic typed languages.
>
> We do have a utility method which does the following:
>
> if (closable != null) closable.close();

Call me ignorant, but I'm not sure who "we" are in the above. The code
looks more like Java or C++ than any dynamic language I know of.

> In Java, you cannot write this method so that it supports InputStream,
> OutputStream, Reader, Writer, Socket, ResultSet, Statement, Connection
> etc. - just because there is no Closable interface (other than using
> reflection, which is basically emulating the feature of dynamic type
> checking).

closable.close(); would not work with any class that doesn't have a
"close" method no matter what language you wish to work with. I would be
very wary of just assuming that a method that happens to have the name
I'm calling will arbitrarily do the right thing if the method wasn't
written with the concept I'm using in mind. IE:

interface MyClosable {
public void close();
}

I can reasonably assume that any class that inherits from the above will
work with any class that uses the above interface as a client, simply
because the class designer had to have the forethought to know what
'close' was supposed to do when inheriting from my particular Closable
class. Even if he was using the adaptor pattern to do such a thing:

class FooClosable implements MyClosable {
private Foo itsFoo;
public void close() {
itsFoo.cleanUpData();
}
}

In the above code, the programmer is explicitly stating that some
designer's concept of "cleanUpData" maps directly to my concept of
"close" for all the places where I use my "MyClosable" interface. Note,
it isn't necessarily the case that JoesClosable.close() maps directly to
MyClosable.close(), but if I see an adaptor that maps the two, then I
know that a programmer knew enough about the MyClosable interface and
the JoesClosable interface and was able to determine that they do indeed
map well.

Daniel T.

unread,
Mar 10, 2004, 11:51:06 PM3/10/04
to
ig...@yahoo.com (Isaac Gouy) wrote:

> "Ilja Preuß" <pre...@disy.net> wrote:
>
> > We do have a utility method which does the following:
> >
> > if (closable != null) closable.close();
> >
> > In Java, you cannot write this method so that it supports InputStream,
> > OutputStream, Reader, Writer, Socket, ResultSet, Statement, Connection
> > etc. - just because there is no Closable interface (other than using
> > reflection, which is basically emulating the feature of dynamic type
> > checking).
>
> So there is no existing interface that includes the method 'close' and
> is implemented by all of the types we wish to assign to the variable
> 'closeable'. The general solution is to define a new interface
> ICloseable and redefine all of the types to implement ICloseable.
>
> In Java (without AspectJ) the only way we can do that is by editing
> the source code for all the class definitions (which wouldn't be a
> great approach even if we had the source code).

Or one could make adaptor classes.


> In Nice, a statically checked language, (and other multimethod
> languages) we can retroactively add a new interface to class
> definitions. Here's one example:
> http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/AspectOrientedMultiMethodEx
> ample

Which is effectively the same as making adaptor classes.

Daniel T.

unread,
Mar 10, 2004, 11:51:07 PM3/10/04
to
In article <pt2v40dv3n3gvp43b...@4ax.com>,
Ron Jeffries <ronje...@REMOVEacm.org> wrote:

> On Wed, 10 Mar 2004 12:53:45 GMT, "Daniel T." <postm...@eathlink.net>
> wrote:
>
> >> However, because of the artificial constraints often imposed, static
> >> typing
> >> can
> >> also force one to a design which is less natural, less rational, than one
> >> would
> >> use in a more dynamic language.
> >
> >What constraints are you talking about? I know of no constraints imposed
> >by static typed languages that don't also exist (implicitly) in dyanamic
> >typed languages.
>
> I'm thinking largely of the constraints around needing to declare everything
> in
> advance, which leads to tons of declared interfaces, and objects that want to
> inherit from lots of them. Offhand, I can't think of anything I couldn't
> program, but I find that the need to do all that declaration makes some
> solutions harder to get to in practice, even though they are technically
> possible.
>
> Does that help to clarify? If not, inquire further ...

I agree, it can be a pain to have to actually write down all the various
interfaces that are running around in your head while coding. Often
times, programmers using static typed languages don't bother and then
curse the language when they can't easily plug in their new class. On
the other hand...

There is real value in the "compilable comment"; code that is ment to
help clarify the design of the system, which the compiler can check.
That's what interfaces are. They put more knowledge of the design *into*
the design, rather than only in the designer's heads.

You see, I believe that all thoses things that need to be "declared in
advance" in a static typed language, also need to be at least conceved
of in advance in a dyanimic typed language, even if they don't need to
be explicitly expressed in the code.

Peter Ammon

unread,
Mar 11, 2004, 12:12:45 AM3/11/04
to
Daniel T. wrote:

Static typing and dynamic typing are not mutually exclusive, and you're
right that statically typed languages are not more limited than
dynamically typed languages.

However, when the generated code depends on the static type information,
suddenly you are limited. The features I enjoy most in dynamically
typed languages, such as the ability to add methods to classes, replace
one class with another, replace one method with another, etc. at runtime
aren't doable in languages that generate code based on static type
information.

--
Pull out a splinter to reply.

Robert C. Martin

unread,
Mar 11, 2004, 12:21:58 AM3/11/04
to
On Wed, 10 Mar 2004 16:20:38 GMT, "Shayne Wissler"
<thalesN...@yahoo.com> wrote:

>
>"Robert C. Martin" <uncl...@objectmentor.com> wrote in message
>news:cmos401b4aa3lu33q...@4ax.com...
>
>> I've been a statically typed bigot for quite a few years. ...
>> When C++ came out, I was an avid
>> adopter, and rabid enforcer of strong typing.
>
>...
>
>> Four years ago I got involved with Extreme Programming.
>
>...
>
>> Since then I have become test
>> infected. I can no longer conceive of writing software without using
>> test driven development.
>
>...
>
>> Life in a dynamically typed world is fundamentally simpler.
>
>...
>
>> Does anybody else feel like this? As more and more people adopt test
>> driven development (something I consider to be inevitable) will they
>> feel the same way I do. Will we all be programming in a dynamically
>> typed language in 2010?
>
>No, I don't, and Bob, do you see the pattern the above? You seem to swing
>from one Extreme to another. How about some moderation?

(sigh).

Robert C. Martin

unread,
Mar 11, 2004, 12:21:56 AM3/11/04
to
On Wed, 10 Mar 2004 12:53:45 GMT, "Daniel T."
<postm...@eathlink.net> wrote:

>Ron Jeffries <ronje...@REMOVEacm.org> wrote:
>
>> On Tue, 9 Mar 2004 23:56:25 -0500, "Universe" <univ...@tAkEcovadOuT.net>
>> wrote:
>>
>> >Static typing would tend to enforce a rational object model, more oriented
>> >toward initial up-front analysis, it seems.
>>
>> Partly yes, partly no. Static typing constrains, often severely, what one can
>> do, or the difficulty of doing it. This places a higher value on up-front
>> consideration, to avoid dead ends.
>>
>> However, because of the artificial constraints often imposed, static typing
>> can
>> also force one to a design which is less natural, less rational, than one
>> would
>> use in a more dynamic language.
>
>What constraints are you talking about? I know of no constraints imposed
>by static typed languages that don't also exist (implicitly) in dyanamic
>typed languages.

Imagine that you have a derivative that has a method. You are adding
code to that method and decide that you need to throw an exception.
No other implementations of that method in other derivatives throw
exceptions. Hundreds of modules call the function through the base
class interface. Hundreds of other modules use the base class
interface without calling the method.

How many source files need to be changed to accommodate the "throws"
clause? How many modules must be recompiled because of those changes.
How many DLLs or jar files must be redeployed because of those
recompilations?

If the answer to any of those questions is a number larger than one,
then that represents a constraint that a dynamically typed language
doesn't have -- even implicitly. If the build time for the change is
much larger than a second, then that represents a constraint that a
dynamically typed language doesn't have.

Robert C. Martin

unread,
Mar 11, 2004, 12:21:58 AM3/11/04
to
On Wed, 10 Mar 2004 07:51:39 -0800, thoff <t...@possibility.com> wrote:

>
>
>Robert C. Martin wrote:
>> Does anybody else feel like this? As more and more people adopt test
>> driven development (something I consider to be inevitable) will they
>> feel the same way I do. Will we all be programming in a dynamically
>> typed language in 2010?
>
>You are saying a dynamically typed language is the best choice
>for all circumstances?

No, I was simply asking whether anyone who practices TDD has found
that no longer value static typing as much as they used to.

>Your choice is based on the assumption that people will write
>unit tests and maintain them.

My choice is based on the fact that *I* will write and maintain unit
tests. I wonder if anyone else who will behave the same way, has made
the same decision that I have.

>That is simply not a justifiable
>assumption in 95% of the people i have ever worked with. Even
>those that do use TDD i have found the quality of the effort is
>still very developer specific.

The question is whether it is enough for each of them individually to
make the same decision I did. I'm not asking if this is a good thing
or not. If TDD continues to be practiced more and more, will each
individual relax their reliance on static type checking?

>Given my assumption then i must use judgement as to what is
>important in what situation. I know, we rather replace judgement
>with simplistic rules, but i still think judgement is what
>professionals with experience can bring to the game.

Of course. Indeed, my question is about such a judgement call.

>I use perl and no unit testing for even
>very complicated web sites and that works well enough 99% of
>the time because i find bugs are rare regardless of the methodology.
>Few people work on the system. No problem. Unit testing in this
>case is an uncessary burden.

I, on the other hand, have found that writing unit tests concurrently
with code is less burdensome than not writing them, even in very
simple systems. This is a personal decision that applies to me and
may not apply to everyone.

>On another system that is a C++ based in a very complex embedded
>environment with a 100 developers of different abilities spaced
>all over the country. A single mistake can cost millions. In this
>environment i very glad for static type checking because i *know*
>i can not rely on people writing and updating unit tests. The overhead
>of defining abstract interfaces is very small in this scenario
>given the payoff.

I wonder. Given a team of experienced folks who conscientiously
practice TDD, could they use a dynamically typed language to deliver
the project faster, cheaper, and better? I think it could be.

>I find absolute rules, though they make good grist for discussion,
>are not that useful because you must find a solution that meets
>your requirements and your problem space. Assuming into existence
>a group of engineers who write high quality unit tests and update
>them 100% of the time is a very hard precondition.

200 years ago you'd have had trouble finding doctors who bothered to
wash their hands before surgery. Nowadays you won't find one who
doesn't *diligently* wash his hands. 25 years ago you'd have had
trouble finding a software developer who didn't use goto. Nowadays
they are pretty rare. Practices change, and it doesn't really take
that long for them to change. I think it's possible that in a few
years TDD could be viewed as a standard of professional behavior.

Robert C. Martin

unread,
Mar 11, 2004, 12:21:57 AM3/11/04
to
On Wed, 10 Mar 2004 12:55:33 +0000 (UTC), Peter Hermann
<ica...@sinus.csv.ica.uni-stuttgart.de> wrote:

>Robert,
>I know you since more than one decade as a strongheaded Ada ignorer.

I am certainly an Ada ignorer. The ignorance is not strongheaded
however. I'd like to learn Ada. I've just never had the need.

>Nevertheless I read your whole contribution and again shook my head.
>All your needs are fulfilled by Ada, hands down.

I don't know, but I thought that large Ada systems might have build
times in excess of one second; or that if I change a function
signature in one Ada module I might have to recompile many other
modules -- even those that don't call it. Am I mistaken?

Phlip

unread,
Mar 11, 2004, 12:54:08 AM3/11/04
to
Robert C. Martin wrote:

> No, I was simply asking whether anyone who practices TDD has found
> that no longer value static typing as much as they used to.

Before TDD, I would refactor by changing a C++ header file, predict that the
compile would dislike the types of each implementation line that needed
attention, then use the "Next Diagnostic" function key to navigate to each
of those lines and fix them.

After TDD, I make small refactors after writing deliberately bad code to
pass a test. The size and scope of any other kind of refactor has gone way
down (but there's still the occassional party). The ability to navigate code
by forcing type errors is not needed, hence not missed.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces


thoff

unread,
Mar 11, 2004, 1:21:05 AM3/11/04
to

Robert C. Martin wrote:
> The question is whether it is enough for each of them individually to
> make the same decision I did. I'm not asking if this is a good thing
> or not. If TDD continues to be practiced more and more, will each
> individual relax their reliance on static type checking?

What you would do personally matters for your personal programming.
My focus is always on pretty complex projects. In that context
it is the project and the characteristics of the group and
management that will decide. It can't be an individual choice,
no more than language selection in a project is an individual choice.

> I, on the other hand, have found that writing unit tests concurrently
> with code is less burdensome than not writing them, even in very
> simple systems. This is a personal decision that applies to me and
> may not apply to everyone.

Burdensome is a big word that can mean very different things
to different people. It implies an assessment of tradefoffs
and values. I find it hard to believe you can determine a policy
absolutely for all circumstances.

> I wonder.

I unfortuntately don't have to.

>Given a team of experienced folks who conscientiously
> practice TDD, could they use a dynamically typed language to deliver
> the project faster, cheaper, and better? I think it could be.

A team of experienced people who get to conscientiously do anything
will deliver the project faster, cheaper, and better. I have
seen this many times. When a team consists partly of
unconscientious people or are who are not allowed to act
conscientiously, then it becomes very difficult to succeed
period.


> 200 years ago you'd have had trouble finding doctors who bothered to
> wash their hands before surgery. Nowadays you won't find one who
> doesn't *diligently* wash his hands.

And do you find studies supporting this practice? Interestingly
i recall Dr Dean Edell saying there wasn't.

>25 years ago you'd have had
> trouble finding a software developer who didn't use goto. Nowadays
> they are pretty rare. Practices change, and it doesn't really take
> that long for them to change. I think it's possible that in a few
> years TDD could be viewed as a standard of professional behavior.

Good is standard behaviour yet evil still thrives. One solution
the problem of evil has been fundamentalism.

Tsolak Petrosian

unread,
Mar 11, 2004, 2:18:30 AM3/11/04
to
"Shayne Wissler" <thalesN...@yahoo.com> wrote in message news:<qfH3c.97449$ko6.784823@attbi_s02>...


Here is problem with static types:

Lets assume that some method "m" which as parameter needs an object
with both types of T1 and T2 which dont share any commonality (like be
Displayable and Persistable).
How do you define "m"?
The only solution is to define it as m(Object o).

Tsolak Petrosian

Ilja Preuß

unread,
Mar 11, 2004, 4:22:30 AM3/11/04
to
Isaac Gouy wrote:

> In Nice, a statically checked language, (and other multimethod
> languages) we can retroactively add a new interface to class
> definitions. Here's one example:
>
http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/AspectOrientedMultiMethodExample

I fear I don't understand that example. Where in that code is a new
interface retroactively added to a class definition?

Thanks, Ilja


Ilja Preuß

unread,
Mar 11, 2004, 4:33:09 AM3/11/04
to
Daniel T. wrote:
> "Ilja Preuß" <pre...@disy.net> wrote:

>> We do have a utility method which does the following:
>>
>> if (closable != null) closable.close();
>
> Call me ignorant, but I'm not sure who "we" are in the above. The code
> looks more like Java or C++ than any dynamic language I know of.

Sorry, we means "the team I am working with at work". And it is Java, so we
actually face the problem that conceptually it is one method, but we need to
redefine it for any base type we want to use it for.

>> In Java, you cannot write this method so that it supports
>> InputStream, OutputStream, Reader, Writer, Socket, ResultSet,
>> Statement, Connection etc. - just because there is no Closable
>> interface (other than using reflection, which is basically emulating
>> the feature of dynamic type checking).
>
> closable.close(); would not work with any class that doesn't have a
> "close" method no matter what language you wish to work with.

Correct. I can't remember ever having tried to use the method with an object
not having a close method, though. The typical use is

InputStream in = null;
try {
...
}
finally {
StreamUtilities.close(in);
}

> I would
> be very wary of just assuming that a method that happens to have the
> name I'm calling will arbitrarily do the right thing if the method
> wasn't written with the concept I'm using in mind.

The purpose of the method is to close a non-null object, whatever that means
for that object. I don't see how that could go wrong with any implementation
of close().

> IE:
>
> interface MyClosable {
> public void close();
> }
>
> I can reasonably assume that any class that inherits from the above
> will work with any class that uses the above interface as a client,
> simply because the class designer had to have the forethought to know
> what 'close' was supposed to do when inheriting from my particular
> Closable class.

How do you know that??? All that interface is saying is that the object has
a close method. It doesn't seem to imply anything about what close is meant
to do. Anyway, for my purpose, *any* implementation of close would suffice.

> Even if he was using the adaptor pattern to do such a
> thing:
>
> class FooClosable implements MyClosable {
> private Foo itsFoo;
> public void close() {
> itsFoo.cleanUpData();
> }
> }
>
> In the above code, the programmer is explicitly stating that some
> designer's concept of "cleanUpData" maps directly to my concept of
> "close" for all the places where I use my "MyClosable" interface.
> Note, it isn't necessarily the case that JoesClosable.close() maps
> directly to MyClosable.close(), but if I see an adaptor that maps the
> two, then I know that a programmer knew enough about the MyClosable
> interface and the JoesClosable interface and was able to determine
> that they do indeed map well.

Yes, ok.

But for my purpose it doesn't work, because you can't delegate to null. So
you had to have a check for null in every adapter, which basically makes it
a useless concept in this case, unless I am missing something... :(

Take care, Ilja


Peter Hermann

unread,
Mar 11, 2004, 4:33:27 AM3/11/04
to
Robert C. Martin <uncl...@objectmentor.com> wrote:
> I don't know, but I thought that large Ada systems might have build
> times in excess of one second; or that if I change a function
> signature in one Ada module I might have to recompile many other
> modules -- even those that don't call it. Am I mistaken?

These problems existed indeed 20 years ago for large systems.
Today we have clever compilers with clever library concepts
which compile the minimum amount of code but not fewer,
since respecting interdependencies is the real strength of Ada.

--
--Peter Hermann(49)0711-685-3611 fax3758 ica...@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Ilja Preuß

unread,
Mar 11, 2004, 4:37:40 AM3/11/04
to

I do have a concept of "close this object if it isn't null" which is needed
in many places. As I don't like duplication, I want to put this concept in
exactly one place. In Java, I haven't yet found a way to do that.

Did I make myself more clear?

Take care, Ilja


Dmitry A. Kazakov

unread,
Mar 11, 2004, 5:35:43 AM3/11/04
to

You have to recompile the modules depending on the module which
interface contains the signature. If that modules do not call the
function, then the design with respect to how decomposition into
modules was made, is not good, provided that the function has to
undergo permanent signature changes (?) being simultaneously a part of
a module interface! Altogether this example is quite abstract. In
practice, due to strict checks imposed by the language, you will
probably unable to get your module interface compiled, if it contains
a "crazy" function falling out of design. Once you get the interface
right, you will unlikely need to change it ten times per day using it
in hundreds of other modules at the same time. When still the
compilation time became an issue, one should better scrap the whole
project.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Dmitry A. Kazakov

unread,
Mar 11, 2004, 5:47:55 AM3/11/04
to
On Thu, 11 Mar 2004 10:37:40 +0100, "Ilja Preuß" <pre...@disy.net>
wrote:

>Daniel Parker wrote:

package Closable_Things is
type Closable is abstract tagged private;
procedure Close (Object : in out Closable'Class);
-- Called to close an object of any type
procedure Do_Close (Object : in out Closable) is abstract;
-- Implements closing, to be overriden in children
private
type Closable is abstract tagged record
Is_Null : Boolean := True;
end Closable;
end Closable_Things;

package body Closable_Things is
procedure Close (Object : in out Closable'Class) is
begin
if not Object.Is_Null then
Do_Close (Object);
Object.Is_Null := True;
end if;
end Close;
end Closable_Things;

I doubt if that difficult to do in either Java or C++.

Paul Campbell

unread,
Mar 11, 2004, 6:04:34 AM3/11/04
to

"Ilja Preuß" <pre...@disy.net> wrote in message news:c2pbol$5cs$1...@stu1id2.ip.tesion.net...

> > I would
> > be very wary of just assuming that a method that happens to have the
> > name I'm calling will arbitrarily do the right thing if the method
> > wasn't written with the concept I'm using in mind.
>
> The purpose of the method is to close a non-null object, whatever that means
> for that object.

> I don't see how that could go wrong with any implementation
> of close().

Your assuming that "close" is always the last thing you want to do with an object, that
may not be the case e.g.

Class RelayController {
void open() ..
void close() ...
}

Paul C.


Paul Campbell

unread,
Mar 11, 2004, 6:09:08 AM3/11/04
to

"Robert C. Martin" <uncl...@objectmentor.com> wrote in message news:u7pu40lee08i8d7j6...@4ax.com...

> >What constraints are you talking about? I know of no constraints imposed
> >by static typed languages that don't also exist (implicitly) in dyanamic
> >typed languages.
>
> Imagine that you have a derivative that has a method. You are adding
> code to that method and decide that you need to throw an exception.
> No other implementations of that method in other derivatives throw
> exceptions.

Well thats one hell on an LSP violation - as I'm sure you know :-).

Paul C.


Paul Campbell

unread,
Mar 11, 2004, 6:29:20 AM3/11/04
to

"Tsolak Petrosian" <tso...@yahoo.com> wrote in message news:a052897d.04031...@posting.google.com...

> Here is problem with static types:
>
> Lets assume that some method "m" which as parameter needs an object
> with both types of T1 and T2 which dont share any commonality (like be
> Displayable and Persistable).
> How do you define "m"?
> The only solution is to define it as m(Object o).

If they dont share any commonality then then surely there is *nothing* you
can usefully do with such an object other than an explicity dispatch using
an if statement to test its type.

Paul C.


Roger Racine

unread,
Mar 11, 2004, 7:45:22 AM3/11/04
to
Robert C. Martin <uncl...@objectmentor.com> wrote in message news:<bt6v409vm5cf909oq...@4ax.com>...

Rational had an Ada compiler that did not recompile modules that did
not truly need the modifications. I don't know if it still exists (I
haven't been able to use their compilers for a while), but there is
nothing in the language that prohibits compilers from this. When I
asked one vendor why they didn't support that type of feature they
said that compilation times were so fast it wasn't necessary. I
disagree with that vendor's position.

So the answer to your question is that you are exactly correct: you
-might- "have to recompile many other modules -- even those that don't
call it." Then again, you might not.

Roger Racine

Ilja Preuß

unread,
Mar 11, 2004, 8:14:26 AM3/11/04
to
Paul Campbell wrote:

>> I don't see how that could go wrong with any implementation
>> of close().
>
> Your assuming that "close" is always the last thing you want to do
> with an object, that may not be the case e.g.

I am not. The only responsibility of the method is to close the object, if
it isn't null. You can use the method where and when you want.

To reiterate, all the method does is

public static void close(SomeType closable) {


if (closable != null) {
closable.close();
}
}

Take care, Ilja


Ilja Preuß

unread,
Mar 11, 2004, 8:20:54 AM3/11/04
to
Dmitry A. Kazakov wrote:

> package Closable_Things is
> type Closable is abstract tagged private;
> procedure Close (Object : in out Closable'Class);
> -- Called to close an object of any type
> procedure Do_Close (Object : in out Closable) is abstract;
> -- Implements closing, to be overriden in children
> private
> type Closable is abstract tagged record
> Is_Null : Boolean := True;
> end Closable;
> end Closable_Things;
>
> package body Closable_Things is
> procedure Close (Object : in out Closable'Class) is
> begin
> if not Object.Is_Null then
> Do_Close (Object);
> Object.Is_Null := True;
> end if;
> end Close;
> end Closable_Things;
>
> I doubt if that difficult to do in either Java or C++.

Well, I surely don't know how to translate it to Java...

Take care, Ilja


jas

unread,
Mar 11, 2004, 8:53:19 AM3/11/04
to Tsolak Petrosian

Tsolak Petrosian wrote:

> Correct me if I am wrong.

Ok.

> But Ruby, Python and Smalltalk are not truly dynamic languages since
> "object" in those languages cannot dynamically change its type.

Smalltalk is usually considered both strongly typed and dynamically typed.

Strongly - because the sender of a message cannot escape the constraints
imposed by the receiver's type (there is no ability to
re-cast a reference).
Dynamic - because from the sender's point of view, the type of the
receiver is
not bound at compile time; binding is delayed until
runtime - i.e. until
the message is actually sent. The receiver may or may not
change it's
type during execution - the sender does not know, thus the
compiler
cannot generate code which would rely on a statically
determined type.

(Both C++ and Java are statically typed. And weakly typed.)

The primary importance of dynamic binding has to do with parameters -
parameters are not statically annotated with type information.
Hence, any object can be sent as a parameter.

This *seems* to be a reduction in safety.
If you are a C++ programmer, you are used to an illusion.
If you are a Java programmer who would specify the class
of a parameter, you are used to the same illusion.
But if you would *always* specify an interface,
rather than a class, AND you *always* specify
an interface which is minimal, then yes, Smalltalk
does reduce safety *for you*, a little bit.
(We have other tools which compensate for the loss).

Objects can also dynamically change type in at least two ways:
* self changeClassToThatOf: thisOtherObject.
* self become: someOtherObject.

The former changes just the object's class, and is only valid
when the two objects are the same "shape" (meaning instance
variables defined for the two objects are the 'same' in both
number and kind).

The latter causes all references to 'self' (across the entire system)
to be replaced by a reference to the specified object (of any type).
{Hence said change may or may not result in a type change.}

These are quite powerful, hence useful.
And like nitro glycerine, they really shouldn't be tossed about
willy nilly, for similar reasons.

-cstb

Dmitry A. Kazakov

unread,
Mar 11, 2004, 9:11:26 AM3/11/04
to
On Thu, 11 Mar 2004 14:20:54 +0100, "Ilja Preuß" <pre...@disy.net>
wrote:

>Dmitry A. Kazakov wrote:

Forget Java, (:-)) Ada compilers translate directly into Java byte
code. For example JGNAT (free), Aonix ObjectAda (commercial).

Paul Campbell

unread,
Mar 11, 2004, 9:34:11 AM3/11/04
to

"Ilja Preuß" <pre...@disy.net> wrote in message news:c2poni$vo1$1...@stu1id2.ip.tesion.net...

Any void return method by causes no state change is by definition
redundent. Therefore you must be making assumptions about what
it will do otherwise there is simply no point in calling it at all.

Let me put this another way: what will *not* happen if you dont
call this method that will adversely impact the functioning of the
system ?.

Paul C.

Shayne Wissler

unread,
Mar 11, 2004, 10:46:18 AM3/11/04
to

"Tsolak Petrosian" <tso...@yahoo.com> wrote in message
news:a052897d.04031...@posting.google.com...

> Here is problem with static types:


>
> Lets assume that some method "m" which as parameter needs an object
> with both types of T1 and T2 which dont share any commonality (like be
> Displayable and Persistable).
> How do you define "m"?
> The only solution is to define it as m(Object o).

Why is that a problem?


Shayne Wissler


Ilja Preuß

unread,
Mar 11, 2004, 11:08:09 AM3/11/04
to
Paul Campbell wrote:
> "Ilja Preuß" <pre...@disy.net> wrote in message
> news:c2poni$vo1$1...@stu1id2.ip.tesion.net...
>> Paul Campbell wrote:
>>
>>>> I don't see how that could go wrong with any implementation
>>>> of close().
>>>
>>> Your assuming that "close" is always the last thing you want to do
>>> with an object, that may not be the case e.g.
>>
>> I am not. The only responsibility of the method is to close the
>> object, if
>> it isn't null. You can use the method where and when you want.
>>
>> To reiterate, all the method does is
>>
>> public static void close(SomeType closable) {
>> if (closable != null) {
>> closable.close();
>> }
>> }
>>
>
> Any void return method by causes no state change is by definition
> redundent.

The method will cause the state change the object finds to be reasonable
when it receives the close message. The method assumes nothing at all about
what that state change will be or when it should be used. That is the
responsibility of the caller.

Take care, Ilja


Tsolak Petrosian

unread,
Mar 11, 2004, 11:24:43 AM3/11/04
to
"Paul Campbell" <p.au.l.ca...@ob.jectvi.sion.c.o.u.k> wrote in message news:<107900456...@ersa.uk.clara.net>...

What you mean I cannot do anything useful with that object?
The usefulness comes from the contract that the Object passed will
implement these two types.
And there will not be any "ifs" if it were dynamic language but will
be for static languages in order to do cast and do pre condition
check.

Tsolak Petrosian

Isaac Gouy

unread,
Mar 11, 2004, 11:52:12 AM3/11/04
to
"Ilja Preuß" <pre...@disy.net> wrote in message news:<c2pb4n$45t$1...@stu1id2.ip.tesion.net>...

> I fear I don't understand that example. Where in that code is a new
> interface retroactively added to a class definition?

My apologies, that example shows a new interface retroactively added
to an interface definition ;-)

See "Example 9.4. Abstract Interfaces" in the Nice Manual
http://nice.sourceforge.net/manual.html#ex:abstractInterface

//Make strings pass straight through as DEBUG info.
class java.lang.String implements LogEntry;

//Make throwables print a stack trace, plus a message
class nice.lang.Throwable implements LogEntry;

//We like to log requests, too
class javax.servlet.http.HttpServletRequest implements LogEntry;

Ilja Preuß

unread,
Mar 11, 2004, 12:01:17 PM3/11/04
to

Well, hard to forget Java if you already have hundreds of thousands of lines
of working code...

Also, if I contrast the above code to that of a dynamically typed language
to get the same result, I'm not sure I actually *would* like to use Ada. But
that could just be the ignorance of the ignoramus... ;)

Take care, Ilja


Ilja Preuß

unread,
Mar 11, 2004, 12:04:27 PM3/11/04
to
jas wrote:

> (Both C++ and Java are statically typed. And weakly typed.)

As far as I can tell, Java actually is strongly typed (you get a
ClassCastException when you cast to a type an object doesn't support).
Modern C++ also has a similar option, as far as I know.

Take care, Ilja


Universe

unread,
Mar 11, 2004, 12:50:21 PM3/11/04
to

"Ilja Preuß" <pre...@disy.net> wrote in message
news:c2q66s$rd8$1...@stu1id2.ip.tesion.net...

Yes it does. I take C++ as strongly typed wrt statically bound classes.
The nice thing is that , you can get a fair amount of type "bending" using
run-time binding, and *still* have strong typing. OTOH one can encourage a
range of dynamic typing using conversion operators and of course there's
polymorphic adaptation using inheritance and template hierarchies. All
around C++ has an "accurately, wide latitude" type system and idiom.

Elliott
--
Though types only make sense relative to context, system worthwhile
types are *objectively* significant for the relative context.
--
Model the World to a Bright Future!


Paul Campbell

unread,
Mar 11, 2004, 12:57:16 PM3/11/04