Validations Are Best Done At Runtime With Full Language Symantics, Addendum 1
written by Peter William Lount
August 13th, 2004
Addendum 1, Version 1, 20040813 4:15pm PDT
Version 2, 5:01pm PDT

Version 3, 8:33pm PDT, Additional comments by Isaac Gouy, Corrected spelling.

Version 4, 20040814 1:00am PDT

Ok, Isaac Gouy took up the challenge and wrote the Java equilivant of:

with a comment here:
No big "WOW" Isaac ! If you understand "why" Java has some runtime reflection capabiliites you'll be closer to understanding the Smalltalk style.

How long did it take you to write the Java example Isaac?

Also, your example is incomplete, what type is your "aVariable" defined as?

What about C, C++, Haskell, Perl, Phython, etc...? Anyone have examples for other langauges?

By the way the Smalltalk version can be tightened up.

And in Squeak with "object expression arrays" even more so. An "object expression statement" returns an array object with an element for each full Smalltalk expression (including the expression terminating period when needed to seperate distinct expressions) between the curly braces. It's a fast and efficient way to create objects in Squeak Smalltalk.

Now that's a lot cleaner that the other Smalltalk versions. I noticed that the Java version has lots of extra cruft due to it's langauge syntax. One appealing aspect of Smalltalk is it's fairly clean and minimal language syntax.

The fact that Java has some reflection capabilities and permits this similar style of runtime type checking is excellent, and in fact if you read the articles in this series I've mentioned that this is a characteristic of dynamic langauges with sufficient reflection capabilities.

The title of this article is "Validations Are Best Done At Runtime With Full Language Symantics" and that's what your Java example does. So your're supporting a Smalltalk style or the "runtime validation" style of programming with your example in Java.

The take home point is that in Smalltalk you make use of the language and it's relfection capabilities when you need to do runtime type validations and that you have the full language syntax and meta reflection capabilities available to you. There is no other choice (unless you're using a typed variant of Smalltalk - they do exist but aren't in use much).

It's well know that Java's reflection capabilities are now where near Smalltalk's level of sophistication. Hopefully Java develops and improves in this regard, however there are limitations in their Virtual Machine design that limit what they can do and they are very conservative about chaninging the VM out from under people to add new capabilities. In desiging Zoku I've been able to exand the Zoku langauge meta and reflection capabilities beyond what current Smalltalk, Self, Slate, Io, or other langauges that I'm aware of provide. There is a continuim of going from "static" compile time reflection capability ( essenailly none) though partial relfection (i.e. Objective-C, Java, and company) through Smalltalk (and Smalltalk like systems) through more advanced systems like the Zoku Smalltalk variant. It's likely that addition reflection capabilites will be added that take languages beyond the level of Zoku. That is progress.

The key is that most Java programmers are NOT likely to be doing meta type checking like this as most of their code is busy using static type checking! They'd never or rarely need this because the style they use limits it's need considerably! It's likely to be used when they want additional dynamism, in which case it's nice that they have some choices, which just further reinforces the point about runtime validations being the best place for type checking in you want advanced dynamic software systems.

In fact this kind of type checking is rarely needed in Smalltalk! But it's there if you need it and for completeness. Often it's more expediant to use "isKindOf: aClass" than more advanced techniques such as "double dispatching".

The point of the examples in this series of articles is to illuminate where the dymanic power comes from and how it's constrained via the simple yet restrictive idea of "typed variables". The examples are not necessarily examples of code that people frequently use in production systems. Many Smalltalkers consider "isKindOf:" to be bad style as it clearly pulls toward explicit "type checking" and all of it's pitfalls. The examples did however illustrate that control flow choices are possible with runtime type checking v.s. no control flow choices with the simple static typed variables. That's the point of the articles, to illustrate clear examples of how the two styles of programming differ and what the benefits are.

Isaac wrote:

As for my "advocacy" I think it shows consistent support for the Smalltalk style of dynamic programming langauges. It shows an attempt to provide clear examples to people of the differences between Smalltalk and other langauges, especially "typed variable languages" (in this series of articles). It shows that I'm willing to make corrections and fit comments such as Isaac's into the presentation in a way that supports the clairification of the differences between programming languages and styles. I am comitted to being professional in my writing and respectful of others in content and tone.

Updated, Isaac wrote:
Yes, multiple dispatch languages such as those you listed have that interesting language feature. It may even be a useful feature to incorporate into future versions of Smalltalk. Slate Smalltalk has done so already in an interesting way. The point is still that care must be taken in Smalltalk - as in any other language - when dealing with variable type constraints to not over constrain the program.


Again Java sticks to "compile time" solutions rather than pushing the envelope with dynamic runtime solutions that enable more powerful solutions. In this case the solution would be multiple dispatch with inferred types of the parameters at runtime.

---

Copyright 2006 by Smalltalk.org™, All Rights Reserved.