mutate an object or create a new one?

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
 
?

=?ISO-8859-1?Q?Arne_Vajh=F8j?=

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!

Probably never.

That kind of things should be left to the compiler.

Arne
 
T

toton

Chris said:
Who knows, indeed ;-)



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
Thanks for pointing out the link. Will check it for sure!
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 ;-)
There is a fare chance that a "Good programmer" (not me! ) "sometimes"
do better job that a "machine". That is what C++ world claims (I am not
too sure about it though).
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).
I like 4th Point, and playing with it. But "package" was meant to be
something different, rather than access control technique (a name
resolution technique).
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.
If Document needs to parse it's data by own, it need to be like a
parser. And it need to parse all of the supported data. Document is the
"model" ,file is the "view", and parser is the "controller". "I feel"
they need to be decoupled.
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 ;-)
Change in byte-code level needs a new JVM to run my code! I need to
modify Jikes RVM then (which I don't think support annotation yet). And
surely requires much more knowledge than I have. That is not just
feasible form "me" ! But like the solution, if someone do it. Java
annotation opened a lots of opportunity, which otherwise was only
possible through language extension.
 
C

Chris Uppal

toton said:
I like 4th Point, and playing with it. But "package" was meant to be
something different, rather than access control technique (a name
resolution technique).

I don't know how much the package mechanism was originally intended as a
namespace separation feature, and how much as a code grouping feature, but it
has certainly proved to be mostly useful (and used) for the latter. The
namespace separation is of little use unless there are actual name clashes, but
if there are name clashes then the code is in trouble even /if/ the compiler is
able to disambiguate perfectly. So it's good practise to avoid name clashes
(within reason) -- e.g. not calling a class List or Map. And, as a result,
namespace separation is rarely needed. But the package-level access control is
used /a lot/.

If Document needs to parse it's data by own, it need to be like a
parser. And it need to parse all of the supported data.

That's not what I meant. I said that it had /responsibility/ for parsing the
data -- that isn't at all the same thing as it containing any parsing code (the
responsibility could be, and would be, delegated). The point (in this
particular design option) is that the users of Documents don't know about
Parser objects -- only the Documents themselves do.

Document is the
"model" ,file is the "view", and parser is the "controller". "I feel"
they need to be decoupled.

I'm sorry, but I don't understand that. I always get confused when people
start talking about MVC outside its original application domain (constructing
GUIs). Even if I can see some sort of resemblance between the components'
roles and those of their "equivalents" in classic MVC, I can very rarely see
any point in making the comparison (I don't usually see how the metaphor makes
the concepts any clearer).

Change in byte-code level needs a new JVM to run my code! I need to
modify Jikes RVM then (which I don't think support annotation yet). And
surely requires much more knowledge than I have.

As a matter of fact Java bytecode has remained very stable over the years --
much more so than Java the language. And of course, you don't need a whole JVM
just to analyse the bytecode -- there are several libraries available which
will do that for you. ASM seems to be the most popular these days. I'm not at
all urging you to become a bytecode expert (you seem to be having enough fun
with compilers for now ;-), but bytecode analysis is easier (and more
interesting[*]) than I think most Java programmers realise.

-- chris

([*] if you have the right kind of mind ;-)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top