C
Chris Uppal
toton said:Maybe someday Java will have an @valueType attribute to "help" memory
allocation for non-polymorphic objects (final objects), and the
collection will "hold" the value type objects! Who knows!
Who knows, indeed ;-)
Heard sun is opening up its C++ sourcecode for JIT , eager to look at
the "bleeding edge" techniques.
You already can download the source for the whole 1.6 platform from the same
page as the JDK itself. Note that the licence may not be acceptable, so do
read it first.
http://java.sun.com/javase/downloads/ea.jsp
To put it another way, its a fair bet that the JVM can
That always one programmer wants! But a human never wants a machine to
overperform him! what a irony!
It requires a certain mental agility. Essentially its a matter of
reclassifying a task (such as memory management) from "it's challenging and
tricky and takes a good programmer to do it properly" to "this stuff is tedious
and too boring to bother with -- let the computer do it!". The trick is to be
able to change your stance quickly and seamlessly according to the system
you're working with at the time ;-)
It is again like, I want an immutable class, but the class is big! How
to set all of the fields within constructor? It will be a huge list. [...]
I "feel" there must be a better way.
The only ways I know of are:
1) Pass a huge list of parameters to the constructor -- not nice.
2) Pass an object /containing/ all the data to the constructor. That object
(which might be a generic object such as a Map in some cases) is mutable
itself, but the object which populates itself from that data is not.
3) The downside of (2) is that you replicate the field list; it might be
simpler to keep the "seed" object in your real object as a single field, and
use that to hold the data at runtime. It doesn't save an awful lot of code,
though.
4) Play games (simple or sophisticated) with access control. For instance all
the initialisation could be via package-private methods, or even via private
methods (in which case you'd have a static factory method for creating the
things).
I think that all the "tricks" you can play with inner or nested classes amount
to some variation/combination of the above (albeit, perhaps, packaged more
nicely).
In the particular case you describe, I would be tempted to approach this at an
OO design level, rather than as a how-to-make-the-code-say-what-I-want level.
That's to say, I would be tempted to give the objects the responsibility for
populating themselves (taking that job away from the parser). So the object
would have ultimate responsibility for parsing; and it would /delegate/ some or
all of that responsibility to parser objects which it used internally. The
protocol for communication between the parser and the object which used it
would be designed so that the parser yielded up information about the various
aspects of the input rather than attempting to use that data to construct a
Document object itself. That's just a thought, of course, it might make no
sense at all for your actual application.
In the meantime writting a Java "preprocessor" which recognizes const
keyword and do check! However no runtime check. In progress ! Will add
a good skill to my compiler knowledge! Not something serious, Just for
fun! The Java project is also my personal one only, as a hobby.
Fair enough. I hope you enjoy the project !
It wouldn't suit me -- but then I find Java's syntax over-complicated and
wouldn't want to spend more time working with it than I had to. My impulse
would be to try to do something at the bytecode level (much cleaner than Java
for many things), such as adding an annotation to methods which meant "should
only be called (directly or indirectly) from the constructor", and then to scan
the class files to look for potential violations of the rule. Not really very
practical, but it could be fun ;-)
Each to his own...
-- chris