>>>>> "Richard" == Richard Jones <[EMAIL PROTECTED]> writes:
> Java News-collector wrote:
>>
>> Obviously you have limited knowledge/experience with the internals of
>> object-oriented environments. I wouldn't be too quick to call the object
>> construction/initialization sequence "dumb" without a detailed analysis.
>>
>> I would be inclined to say that calling an abstract/virtual method that
>> must be defined in a subclass from within a constructor is a bad/dangerous
>> programming practice that will yield unpredictable results, at best.
> Maybe so, but I thought the whole point
> of Java was to provide me with a language
> where I couldn't shoot myself in the foot.
Heh - a language that you can't shoot yourself in the foot with isn't
likely to be very useful. I think the java philosophy was more like
"make simple things simple and complex things possible." (can anyone
supply the attribution?)
> The worst thing about this particular design
> is that I can call `method()' and update `d'
> in this method, and neither or these provokes
> an error at compile- or runtime. And later the
> Java runtime overwrites `d' (which I set in
> `method()') with the initializer value, which is
> totally contrary to expectations and very
> dangerous.
Hmmm... (IMO) the alternatives are even worse...
1. you could forbid non-constructor (or, at least, downward) method
calls until finalized (many languages take this approach).
2. do a multi-pass construction phase running initializers first and
constructors second (which violates some of the class encapsulation
rules - the super isn't yet complete when your initializers run).
3. disallow runtime initializer evaluation (must be compile-time
constant - another favorite in other languages).
4. guard every value and throw an exception if any instance variable
gets initialized after being assigned (considerable extra overhead,
and requires that initialization and assigment be tracked as separate
operations.
At least the Java model is easily understandable once you find the
description in JLS... other languages have rather more complicated
rules (e.g. multiple inheritance, before/after/wrapper/whopper/etc
method combinations, etc).
The point is that you are doing a sufficiently complex thing as to
expose some of the (as always, somewhat arbitrary) language design
choices. As this level, any of the choices would result in someone's
mental model being violated.
Java threading is in an even worse position - the syntax was made so
trivial as to fool people into thinking that writing threaded code is
easy.
Cheers,
-mik
--
Michael Thome ([EMAIL PROTECTED])
