Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > mutate an object or create a new one?

Reply
Thread Tools

mutate an object or create a new one?

 
 
Chris Uppal
Guest
Posts: n/a
 
      10-29-2006
toton wrote:

> 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
> > manage memory faster than you can do it yourself

> 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


 
Reply With Quote
 
 
 
 
=?ISO-8859-1?Q?Arne_Vajh=F8j?=
Guest
Posts: n/a
 
      10-31-2006
toton wrote:
> 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
 
Reply With Quote
 
 
 
 
toton
Guest
Posts: n/a
 
      11-02-2006

Chris Uppal wrote:
> toton wrote:
>
> > 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

Thanks for pointing out the link. Will check it for sure!
>
> > To put it another way, its a fair bet that the JVM can
> > > manage memory faster than you can do it yourself

> > 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

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.
>
> > 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

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.
> Each to his own...
>
> -- chris


 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      11-02-2006
toton wrote:

> 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



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LangWart: Method congestion from mutate multiplicty Rick Johnson Python 51 02-12-2013 08:46 PM
pygene, mutate jenik General Computer Support 0 12-12-2010 10:09 PM
Re: mutate dictionary or list Bruno Desthuilliers Python 0 09-07-2010 01:55 PM
naming convention for functions that mutate their arguments? mike p. Python 1 02-27-2004 02:18 AM
how to mutate a tuple? Carlo v. Dango Python 10 10-14-2003 03:32 PM



Advertisments