Tool for inlining useless getter/setter call

J

Jack

Hi,
is there a tool to inline "useless" getter call:
* simple getter (return field;) or setter (this.field = arg)
* called in the class that contain the field
* getter/setter is not overloaded, and does not overlead (in the current code)

I would like to inline these call automatically in all my java code.
 
O

Owen Jacobson

Hi,
is there a tool to inline "useless" getter call:
* simple getter (return field;) or setter (this.field = arg)
* called in the class that contain the field
* getter/setter is not overloaded, and does not overlead (in the current code)

I would like to inline these call automatically in all my java code.

Sun's Hotspot JVM (and presumably any other JITing JVM) is capable of
inlining these at runtime and will do so automatically unless JIT is
explicitly disabled.
 
D

Daniel Pitts

Jack said:
Hi,
is there a tool to inline "useless" getter call:
* simple getter (return field;) or setter (this.field = arg)
* called in the class that contain the field
* getter/setter is not overloaded, and does not overlead (in the current
code)

I would like to inline these call automatically in all my java code.
They aren't exactly useless. They're their as a stop-gap for the Uniform
Access Principal.
<http://en.wikipedia.org/wiki/Uniform_access_principle>

Since Java doesn't support it directly, people use convention, by always
providing getters/setters for properties.

Now, this doesn't necessarily affect performance, as many JVMs will
inline simple methods while it handles hotspots.
 
L

Lew

Daniel said:
They aren't exactly useless. They're their as a stop-gap for the Uniform
Access Principal.
<http://en.wikipedia.org/wiki/Uniform_access_principle>

Since Java doesn't support it directly, people use convention, by always
providing getters/setters for properties.

Now, this doesn't necessarily affect performance, as many JVMs will
inline simple methods while it handles hotspots.

Better than that, in certain cases the HotSpot compiler will enregister the
values and even avoid creating the container object, doing everything on
registers or the stack.
 
J

Jack

Owen Jacobson a écrit :
Sun's Hotspot JVM (and presumably any other JITing JVM) is capable of
inlining these at runtime and will do so automatically unless JIT is
explicitly disabled.

Thanks, but i would like to remove them from the java source code. The reason is that these accessors hide "what is going on", and i don't appreciate that.

Keeping setter who checking the argument is ok, but simple assignement setters, or simple return getters are really useless, when called from the class which define them.
 
D

Daniele Futtorovic

Owen Jacobson a écrit :

Thanks, but i would like to remove them from the java source code. The
reason is that these accessors hide "what is going on", and i don't
appreciate that.

This sounds like the very contrary of what you should strive for (see
the UAP link Daniel Pitts posted).

Could you elaborate on your reasoning?

df.
 
O

Owen Jacobson

Owen Jacobson a écrit :



Thanks, but i would like to remove them from the java source code. The reason is that these accessors hide "what is going on", and i don't appreciate that.

Keeping setter who checking the argument is ok, but simple assignement setters, or simple return getters are really useless, when called from the class which define them.

Eclipse can do this provided that all the places that you want to
inline it to are within the workspace and have inter-project
dependencies set up right. Go to the definition of the method you
want to inline and Refactor/Inline Method. Other IDEs presumably
offer a similar feature.

You may have to increase the accessibility of the relevant variables.

However, I fundamentally disagree with your premise. I hope I never
wind up maintaining code you've done this to: the number of things
that take advantage of accessor/mutator methods that have a hard time
with raw field access is pretty high, and, particularly for mutable
fields, allowing the world at large to simply stuff values into the
field makes maintaining invariants with respect to that field all but
impossible.

-o
 
J

Jack

Daniele Futtorovic a écrit :
This sounds like the very contrary of what you should strive for (see
the UAP link Daniel Pitts posted).

Could you elaborate on your reasoning?

Daniele:

it's the least of our problems. My boss don't care about anything execpt testing for null everywhere. I didn't even know the word "JavaBean" before i was hired.

So i really don't care about concepts like "UAP".

Owen:
I don't want to remove the accessors. Our "io" package use them for saving/loading. I just want the remove the call sites from the defining class, and eclipse don't do that.

We don't have any "immutable" class, and i think we are never going to have any invariant anywhere in our code. My boss reject them. He prefer "!= null" tests, and a good knoledge/memory of the internals.
 
D

Daniele Futtorovic

Daniele Futtorovic a écrit :

Daniele:

it's the least of our problems. My boss don't care about anything execpt
testing for null everywhere. I didn't even know the word "JavaBean"
before i was hired.

So i really don't care about concepts like "UAP".

This is not so much about Beans as about encapsulation. Instance
property access through methods is arguably an important aspect of good
coding, for polymorphism, maintainability and adaptability.

I would say whether or not you concern yourself with the quality of what
you produce is a matter of self-respect. Your boss' opinion notwithstanding.

df.
 
J

Jack

Daniele Futtorovic a écrit :
This is not so much about Beans as about encapsulation. Instance
property access through methods is arguably an important aspect of good
coding, for polymorphism, maintainability and adaptability.

I would say whether or not you concern yourself with the quality of what
you produce is a matter of self-respect. Your boss' opinion
notwithstanding.

The thing is, HE define the specs, HE change them every week, so i just can't make a good model/design and then implement it.

Now half the time i have to work with code produced by him, so i don't want to develop two "personality" for two kind of code. Every time i must find a bug in his code, i can't think "this shouldn't be done like that". So i'm just resigned.
 
D

Daniele Futtorovic

Daniele Futtorovic a écrit :

The thing is, HE define the specs, HE change them every week, so i just
can't make a good model/design and then implement it.

Now half the time i have to work with code produced by him, so i don't
want to develop two "personality" for two kind of code. Every time i
must find a bug in his code, i can't think "this shouldn't be done like
that". So i'm just resigned.

That sure is a pretty fucked up situation. Whether or not there is any
escape from it is too hard to tell from an outsider's point of view.

On a strictly personal note however, and with all due respect, I would
strongly advise you *not* to resign to this. This can have the most
tremendous and unforeseen negative effects on your personal well-being
and, in the long run, on your personality itself.
 
P

Patrick May

Jack said:
is there a tool to inline "useless" getter call:
* simple getter (return field;) or setter (this.field = arg)
* called in the class that contain the field
* getter/setter is not overloaded, and does not overlead (in the
current code)

I would like to inline these call automatically in all my java code.

How about not creating those "useless" methods in the first
place?

As a rule, getters and setters should be avoided unless
absolutely necessary. They should certainly not be created as a
matter of course.

Regards,

Patrick
 
L

Lew

Jack said:
Owen Jacobson a écrit :
Sun's Hotspot JVM (and presumably any other JITing JVM) is capable of
inlining these at runtime and will do so automatically unless JIT is
explicitly disabled.

Thanks, but i would like to remove them from the java [sic] source code. The
reason is that these accessors hide "what is going on", and i [sic] don't
appreciate that.

As the doctor said, "So don't do that."

Me, I find that accessors and mutators /express/ what's going on. I don't
even begin to remotely understand how anyone could imagine that they hide
what's going on. You see "getFoo()", you know right away that the expression
gets 'foo'. Maybe if one weren't too familiar with the idiom, but that
problem corrects itself with some experience.

In C# code where the properties look more like members, that hides what's
going on, to my eye. You can't tell from a property access expression whether
it's using a direct member or a property, so you don't know if there's any
kind of protection or you're using the value "raw". Much more opaque than the
Java idiom, which self-documents in the expression which is which.
Keeping setter who checking the argument is ok, but simple assignement
setters, or simple return getters are really useless, when called from
the class which define them.

In NetBeans it's easy enough to change the source code - the editor's
search-and-replace facility will let me change every instance of getFoo() to
foo, and setFoo( x ) to this.foo = x (the latter needing regex to rearrange
things easily). This still leaves the question of why accessors and mutators
are used in the same class to begin with if you didn't want them.
 
L

Lew

Jack said:
We don't have any "immutable" class, and i [sic] think we are never going to
have any invariant anywhere in our code. My boss reject them. He prefer
"!= null" tests, and a good knoledge/memory of the internals.

"Rejecting" invariants is like "rejecting" gravity or that the planet is an
oblate spheroid and not flat. One's belief, or lack thereof, doesn't change
that these things exist.

You have invariants in your code; there's no way around it. The problem is if
you don't detect when they're violated.

Your boss doesn't sound like he understands programming at all.

You use tests like "!= null" to enforce invariants with the 'assert' keyword,
to check data values with an 'if' expression. Which you use depends on the
technical factors, not some strange superstition based on utter incompetence.

Why wouldn't you use immutable classes? Does he reject the use of threads?

Does your boss also "reject" for-each loops? He sounds like a total freaking
idiot. Quit that job and work for someone who doesn't micromanage you from a
platform of complete stupidity. You may tell him I said so.
 
L

Lew

Patrick said:
How about not creating those "useless" methods in the first
place?

As a rule, getters and setters should be avoided unless
absolutely necessary. They should certainly not be created as a
matter of course.

Disregard that advice. Use of accessors and mutators is a best practice.
 
P

Patrick May

Lew said:
Disregard that advice. Use of accessors and mutators is a best
practice.

No, it's a bad practice. Wherever possible, objects should be
immutable. Where not possible, follow the rule of "tell, don't ask."
If you have classes that poke around in the internals of other classes
in order to accomplish their goals, you need to repartition your
behaviors.

Widespread use of accessors and mutators is the sign of a poorly
designed system.

Sincerely,

Patrick
 
D

Daniel Pitts

Jack said:
Daniele Futtorovic a écrit :

The thing is, HE define the specs, HE change them every week, so i just
can't make a good model/design and then implement it.

Now half the time i have to work with code produced by him, so i don't
want to develop two "personality" for two kind of code. Every time i
must find a bug in his code, i can't think "this shouldn't be done like
that". So i'm just resigned.
First, take a Java coures and OO design course.
Second, get a job with a manager that doesn't micro-manage.

The whole idea of OO is to "hide" unnecessary implementation details,
your "goal" seems to be to expose those details. Its almost like going
to a restaurant and insisting on watching how they kill the cow for the
steak you're about to eat.

Also, Java automatically "checks for null" for you. That's what the
NullPointerException is for :)
 
D

Daniel Pitts

Patrick said:
How about not creating those "useless" methods in the first
place?

As a rule, getters and setters should be avoided unless
absolutely necessary. They should certainly not be created as a
matter of course.
Actually, you should never have a public field in Java. Also, the more
of your internal implementation uses your own public interface, the less
likely changing any one implementation detail will change other places
in your code.

You shouldn't create a getter/setter for every field, just every field
you want to expose publicly (or protectedly, etc) As well as some fields
that represent properties who's behavior may change in the future.

I often create getters/setters for most of my fields. If I find a place
where I'm doing lots of gettings/settings on the same class, I then
refactor to add that *behavior* that uses those getters/setters to the
object that *has* those getters/setters.
 
D

Daniel Pitts

Patrick said:
No, it's a bad practice. Wherever possible, objects should be
immutable. Where not possible, follow the rule of "tell, don't ask."
If you have classes that poke around in the internals of other classes
in order to accomplish their goals, you need to repartition your
behaviors.

Widespread use of accessors and mutators is the sign of a poorly
designed system.

Sincerely,

Patrick
You're both right.

Accessors and mutators are useful for exposed "properties" of an object.
The tell, don't ask principle is a good one to follow in many cases,
but unfortunately it can greatly complicate simple task if taking to an
extreme. Imaging if you had to use a callback or listener to calculate a
sqrt: Math.calculateSqrt(new MySqrtListener());
Now, MySqrtListener basically has to know the rest of the program (or
expose its results through an accessor. Oops, thats asking!

If Java had support for continuations, that might make more sense. It
doesn't, so "asking" Math for a sqrt is better than "telling" math to
"tell" someone else a sqrt.
 

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

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top