Re: Swing is dead! Long live Swing.
Arved Sandstrom wrote:
I agree with you guys in general, but I'm not sure I see the problem for
the situation we are discussing. Whether it's FXML or Facelets XHTML in
JSF, or XAML over in .NET land [1], you're talking about things that
have strong mappings to the code-behind (whether Java or C#).
There is no need to discover only at _runtime_ that your "strings" were
wrong. Both JSF Facelets XHTML and FXML are amenable to having a great
deal of rigorous checking done by hypothetical toolsets before the
underlying Java ever gets compiled. If a particular method in a
particular Java class is called for, that can be checked in principle
before building.
This approach works well, and tool choice is an important part of programming.
The key principle is to catch problems early and even earlier.
Compilation-level type safety is the strongest tool for that, when applicable.
Post-deployment tools are the weakest. What you describe is between those
extremes.
As I said in my post, there are use cases for offloading type checking from
the compiler. Your suggestions reduce the cost of that decision, making the
cost-benefit analysis tilt more in favor of doing such offloading.
If your hypothetical tool is "screwing you" every time you make a typo
or other mistake when moving, renaming or otherwise refactoring things,
then I suggest that the hypothetical tool sucks...to use technical
terminology. As an example, let's say I've got EL in a JSF Facelets page
that references a couple of managed beans. So you've got references to
the @ManagedBean or @Named names, to the getters/setters in those
classes, and to action methods. You're seriously telling me that a
decent tool couldn't solidly track the reference bindings and do proper
refactorings for that stuff?
I haven't seen anyone make that claim here. Have you? To whom is that question
addressed?
The egregious example I cited was not a case of a tool screwing them. It was a
case of custom fubaration of something simple into a right mess.
One claim I do make is that the further down from compilation to customer use
you go, the worse it is to catch and fix problems. I compared the endpoints;
you provided a midpoint in that spectrum. I do not claim, in fact explicitly
disclaimed that one should never pay such a cost. It's a question of what you
can afford and what it buys you, always.
The problem is that people often unwittingly pay more than they should, and
worse, get no benefit thereby. You must be aware.
With Java you are certain to have a compiler and a runtime. I certainly would
never espouse relying only on those two tools as if none others exist, but the
more you can get the compiler to do, without sacrificing what you need, the
cheaper it is to be right.
Same goes for FXML: where elements of FXML are references to Java
things, a proper tool can clearly maintain the mappings between FXML and
Java.
Surprise, surprise: you actually do have some tools out there that
competently do stuff like this, like IntelliJ IDEA for JSF 2.0.
Does it work with FXML?
And you know, you can thoroughly mess up when renaming, moving or
otherwise refactoring in a pure Java environment too, and all your
compiler will tell you is in how many places [and precisely where! - ed.] you now have a mistake.
Right, but at least you know at compilation and not later.
I've seen plenty of cases where developers - myself included - thought
they knew all the usage sites of something, and figured to manually
refactor. In more than just a few cases that manual refactoring resulted
in something that *compiled* just fine, but was now erroneous, maybe
because you typo'd something. It can absolutely happen, easily actually.
Doesn't IntelliJ reduce the cost of refactoring? Why not use its capabilities
for that?
No one is claiming that compilers and type safety solve all problems. What are
you hoping to prove? The fact remains that errors that *are* caught at
compilation are cheaper to fix than those caught later. The ones that are
missed don't change that.
So using *tool*-assisted refactoring makes much sense. In which case,
why is one kind of tool-assisted management OK and another kind bad?
I'm on your side with this question.
1. XAML not the same thing as the other technologies I mention, but in
one of its uses, as a UI markup language in WPF, there are strong
similarities.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg