Re: Plugins with GUI
On 01/26/2011 05:22 PM, Daniele Futtorovic wrote:
On 26/01/2011 21:12, Lew allegedly wrote:
Lew allegedly wrote:
That is a nice use of 'assert' and one I wouldn't have thought of.
It's a widely-ignored truism that software must be deployed to be
useful. It's hard to bridge deployment aspects to code; this use of
'assert' provides an elegant and sturdy bridge.
Daniele Futtorovic wrote:
Wait, wat?
This?
assert macroDelegate != null : "null delegate to process macro
" + macroName;
Yes. It *is* the sole and only use of 'assert' in the quoted post, so it
could hardly be anything else, could it?
Indeed. That's what got me so puzzled. What other kind of use of
"assert" have you ever encountered?
How so?
First of all, let's restore the context. Roedy Green wrote:
final Macro macroDelegate =
LoadCodeToProcessMacro.getMacroProcessorInstance( macroName );
assert macroDelegate != null : "null delegate to process macro
" + macroName;
This is a pattern quite prevalent in dependency injection (DI), JNDI
lookups, JDBC connections and the like. The 'getFooInstance()' factory
or declarative equivalent pulls in some deployment-specific delegate or
handler, just as in this example, often specified in a resource file or
deployment descriptor.
If that delegate is not correctly deployed or specified, you will get
back a 'null' or throw an exception. (Something like this will usually
be exception-enforced.)
If there is an issue, this gets rectified pretty much once per
deployment. After that, it just works - the correct delegate is deployed
where it belongs.
A check 'if ( macroDelegate == null )' at that point is not helpful.
It's just wasted cycles. A production instance can shut off 'assert'
checking (globally or just for the class), safe in the assertion that
once fixed, the problem is gone. Poof! No overhead.
If the problem recurs, turn on 'assert' and repeat. This should be rare.
So it's elegant - one small 'assert' prevents a raft of difficulties.
It's sturdy - you can guarantee success across a range of scenarios.
Q.E. effing D.
Hardly.
You mention deployment. Either the producer of that code has control
over the JVM parameters, or they haven't.
They don't, but that's not the point.
They know that the deployer has control, and can instrument the code, with
'assert', for their use.
If they haven't, then they cannot assert that assertions are enabled.
Nor need to.
If they have, then they can. But how do they switch them off if they're
The ops personnel do that, duh.
switched on as part of deployment? If they're not switched off, they're
no better than a check and a throw instruction. If they want to switch
They are different from check and throw, neither better nor worse. The
purpose of exceptions differs from that of assertions.
them off after, say, the "tuning phase", then they need either some
post-deployment intervention (and hence to exceed the scope you have
Well, duh, again. That's my point - the ops personnel switch assertions on
and off according to need. Have them on the first day while you make sure
everything is in place, then turn them off when the configuration is correct.
set), or a supplemental mechanism that turns them off based on some
action of an admin -- some configuration utility for instance. How could
that possibly be less a bloat that an added null check?
It's not "bloat", since "bloat" is defined as excess code that doesn't serve a
purpose. This is a tiny injection of code that confirms the presence of an
algorithmic necessity. It's the exact opposite of "bloat".
As for your so-called "supplemental mechanism", I'm not positing any mechanism
beyond that provided by the JVM itself, which of course is always under the
control of an admin's actions. What else would it be?
Furthermore, if what the service provider kind of code needs to succeed
is dynamic, part of the environment, then I don't see at which point you
could ever decide that the check isn't necessary anymore. The
environment can change at any time, due to migrations, restores, updates
or whatever.
I'm not proposing that this technique, or any other, is universally
applicable. Like any other tool in the programmer's kit, it must be
considered within the boundaries of its use case. I spoke only of the use
case where the environmental configuration has roughly deployment lifespan.
You do speak of a different use case where the technique might not apply so
neatly.
In other words, the "assert" in this particular case is at best no
better than an if, and at worst useless, in upon or after deployment.
It is better than an 'if', in the first place because the overhead of the 'if'
can be eliminated by turning off 'assert', in the second because 'assert' and
'if' serve different purposes. The 'if' would enforce the invariant, the
'assert' proves it. Not the same.
In the more conventional application of asserting algorithmic invariants,
you'll usually see both an 'if' and an 'assert'.
I would argue that "assert" is destined to enforce code invariants and
is most useful during the development phase. It is especially useful at
Also the troubleshooting phase in production when something goes wrong. You
can turn on 'assert' and see if an invariant broke.
With this new application inspired by Roedy's example, you can also do that
with environmental invariants.
the boundaries of different components interacting with each other, to
enforce component contracts (especially in light of possible future
modifications of a component by cow-workers).
Or now, in light of possible future modifications of a component's environment.
--
Lew
Ceci n'est pas une pipe.