On Java and C++

[Bent C Dalager]

Or that your variables aren't really of the correct type
to start with. From what I've seen, the majority of
getters and setters don't really do anything, and are
exactly equivalent to public data with a really ugly
syntax.

The primary advantage to encapsulating otherwise public data into
accessors that don't actually add anything is that access to this data
can later be easily changed to do something interesting.

It is a poor man's encapsulation, but it's still better than just
having public data fields.

Cheers
Bent D

 

[Andrey Kuznetsov]

Most of the messages in this thread appear to be written by people who

only know one programming language.

in chronological order:

C64 BASIC
ARM BASIC
ARM Assembler
Motorola Assembler
Pascal
C
Modula 2
Opal (ugly)
VisualBasic
Java.

Andrey

 

[werasm]

The primary advantage to encapsulating otherwise public data into
accessors that don't actually add anything is that access to this data
can later be easily changed to do something interesting.

Yes,

One can change the value (if later computation is required) without
changing the interface. Resolution requirements change come to mind.
All said, how about the client specifying what he want.
template <class T>
struct IfToData //Or model from MVC
{
virtual const T& get( boost::void_<T> ) = 0;
};

....now the one getting specifies what he wants - his data now could
become:
boost::weak_ptr<IfToData<int> > myDataModel_;

This also makes him independent of the client from whom he receives
data...

Regards,

W

 

[Jerry Coffin]

The primary advantage to encapsulating otherwise public data into
accessors that don't actually add anything is that access to this data
can later be easily changed to do something interesting.

If you'd read what I posted (the code in particular)
you'd realize that the same is possible when you DO use
public variables.

It is a poor man's encapsulation, but it's still better than just
having public data fields.

No, it's really not.

 

[Oliver Wong]

The primary advantage to encapsulating otherwise public data into
accessors that don't actually add anything is that access to this data
can later be easily changed to do something interesting.

It is a poor man's encapsulation, but it's still better than just
having public data fields.

The code I'm working with has two classes that do almost the same thing,
because the code was built by merging two other programs together.

<Java>
class NodeToken {
public int beginColumn, endColumn;
}

class Token {
public int startColumn, endColumn;
}
</Java>

I'm trying to merge these two classes together. If they had used accessor
methods, I could have a methods setStartColumn(int) and setBeginColumn(int)
affect the same private field, so that the changes would be seen by either
interfaces. Unfortunately, they didn't use accessor methods, and instead
used public fields, so now I've got to start by adding the accessor methods
to each seperate classes, mark the fields as deprecated, check for all
access to those fields, change those to invoke the accessor methods, then
merge the class, then simplify the API.

- Oliver

 

[Noah Roberts]

The code I'm working with has two classes that do almost the same thing,
because the code was built by merging two other programs together.

<Java>
class NodeToken {
public int beginColumn, endColumn;
}

class Token {
public int startColumn, endColumn;
}
</Java>

I'm trying to merge these two classes together. If they had used accessor
methods, I could have a methods setStartColumn(int) and setBeginColumn(int)
affect the same private field, so that the changes would be seen by either
interfaces. Unfortunately, they didn't use accessor methods, and instead
used public fields, so now I've got to start by adding the accessor methods
to each seperate classes, mark the fields as deprecated, check for all
access to those fields, change those to invoke the accessor methods, then
merge the class, then simplify the API.

Interestingly one thing the Java camp never brought up was the tools
they have available to them to make them more productive. Among those
tools are much more sofisticated refactoring tools. The only one I
have been able to find for C++ has been Ref+ and though it does a lot
it is still missing a lot of refactors you get with just about every
version of Java or .Net refactor tool out there. I'm going to blame
this on parsing.

Encapsulate Member is a very common refactor and comes in most tools,
including Ref+, and makes the above process completely automatic. Pop
up a wizard, set a couple of values, and let it go do its thing. They
usually work quite well and I suspect the Java version to be even more
accurate. You use this refactor when you find a public variable that
needs to be encapsulated in a getter and/or setter so that you can
alter behavior or when you need to change the variable to some other
form and you use it even internally to your class.

 

[maaxiim]

Accessor methods also let you implement pre- and post-conditions
allowing you to formalize DesignByContract.

 

[Bent C Dalager]

If you'd read what I posted (the code in particular)
you'd realize that the same is possible when you DO use
public variables.

My comment was largely based on language neutrality. I would rephrase
it to only cover languages that do not have other means of
accomplishing the same effect.

Data encapsulation is the goal. Trivial getX/setX accessors are a
means to reach that goal, and quite defensible in languages that
provide no other (better) means of getting there.

I need to add that in the context of the original suggestion (that
being able to directly access another object's state is wrong in
itself), your operator-based approach would be equally wrong, only
with a nicer syntax. It remains a poor man's approach to
encapsulation: Any algorithms that need to alter an object's state
should be internal to that object itself, not external to it.

According to this philosophy, you would never write
employee.wage *= 1.1;
You would write
employee.raiseWagePercent(10);

Cheers
Bent D

 

[Bent C Dalager]

Interestingly one thing the Java camp never brought up was the tools
they have available to them to make them more productive. Among those
tools are much more sofisticated refactoring tools. The only one I
have been able to find for C++ has been Ref+ and though it does a lot
it is still missing a lot of refactors you get with just about every
version of Java or .Net refactor tool out there. I'm going to blame
this on parsing.

xref-tech.com has XRefactory. I have only used it on C and Java but I
understand they now support C++.

It's quite expensive for hobby users though, and I blame _that_ on
parsing

Cheers
Bent D

 

[Chris Smith]

For a stupid language nobody uses, the D programming language is doing
remarkably well, having moved up to number 19 on
http://www.tiobe.com/tpci.htm

That means it's a language people mention on web pages, not that it's a
language people use.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

(referring to http://www.tiobe.com/tiobe_index/images/tpci_trends.gif as
of May 2nd, 2006): I wonder what happened in 2004 that made Java drop
considerably, and everything else jump up a bit.

If you read the FAQ, they point out that it was a change in the way
Google indexed web pages. I won't speculate (though, clearly, I'm okay
with implying) about what it means when the single biggest point made by
this index turns out to just be an artifact of their methodology.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

So e.g. Swing, JDBC and Vector are all implemented in Java? Without a
single JNI-call in the code? It seems my knowledge of Java needs an
update.

Considered in turn:

Swing: The major part of Swing is written in Java. There are some small
pieces (the only one that comes to mind is the FileSystemView class)
that are not. Of course, Swing depends on AWT, which is implemented
partly in other languages.

JDBC: The JDBC API is completely written in Java. It would have been
silly to use native code for something that is basically just a bunch of
glue. Whether JDBC drivers are written entirely in Java depends on the
driver. About 90% of them are, but a few are not. Oracle, for example,
provides both a pure Java driver and a driver that uses JNI, but I don't
know of anyone using the latter. The only driver that I've contributed
to and thus worked with closely was PostgreSQL, and that's certainly
100% Java.

Vector: Yes, it's all in Java. Again, it would be silly to implement
this in native code. The result would perform poorly and be harder to
maintain.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Oliver Wong]

Interestingly one thing the Java camp never brought up was the tools
they have available to them to make them more productive. Among those
tools are much more sofisticated refactoring tools. The only one I
have been able to find for C++ has been Ref+ and though it does a lot
it is still missing a lot of refactors you get with just about every
version of Java or .Net refactor tool out there.

It might be that the Java camp assumes that this ease of refactoring is
completely natural, and that all developers have access to the technology.
As others have said, the people best suited to claim one language is
"better" than another, for some definition of "better", are those that have
actually used both languages.

Encapsulate Member is a very common refactor and comes in most tools,
including Ref+, and makes the above process completely automatic.

In my specific case, the code accessing the public field is generated
(I'm working with parser generators, and hence the "Token" class), so I'd
have to actually edit the code that generates the code that accesses these
fields. I think the automated wizards aren't smart enough to deal with that
yet.

- Oliver

 

[Chris Smith]

Java has references.

Unfortunately, the meaning of the term "reference" and "pointer" is
language-dependent. Java certainly does not have references in the C++
sense. All Java identifiers are used to designate distinct variables;
you never have two different variable names that both mean the same
thing.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

ObOffTopic: It appears gcc has a similar problem. I'll have to see if a
"dead" pointer store is mistakenly optimized away in a non-main()
routine; that could lead to some subtle C++ bugs.

Since a store to a NULL pointer results in undefined behavior, it would
not be a mistake to optimize this away, at least according to the spec.
Of course, it would be a mistake for practical reasons.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

For its part Java has its own problems with arrays:

int[] s = new int[]{1,2,3};

Ick, and you say C++ has ugly syntax.

int s[] = {1, 2, 3};

This exact line will also work as expected in Java.

Yes, but it would be bad form in Java. Better to write:

int[] s = {1, 2, 3};

The fact that Java accepts a pseudo-C++ declaration syntax for arrays
for no good reason is not knowledge worth spreading. It was a mistake.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

If you were never meant to be a programmer in the first place I
guess.... Hmm, VB and Java programmer are a lot alike. A river in
Egypt, baby, a river in Egypt....

On the other hand, if you think that making trivial choices like
constitutes the greater part of programming, then I'm quite sure I'd not
want to hire you to write code. When making choices about minor matters
of convention, the ONE overriding concern is how to be consistent so
that other programmers are not constantly guessing at what you did.
Save your creativity for things that affect the quality of the resulting
product.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Jerry Coffin]

[ ... ]

<Java>
class NodeToken {
public int beginColumn, endColumn;
}

class Token {
public int startColumn, endColumn;
}
</Java>

I'm trying to merge these two classes together. If they had used accessor
methods, I could have a methods setStartColumn(int) and setBeginColumn(int)
affect the same private field, so that the changes would be seen by either
interfaces.

This seems to be almost entirely orthogonal to the user
of accessor functions.

Unfortunately, they didn't use accessor methods, and instead
used public fields, so now I've got to start by adding the accessor methods
to each seperate classes, mark the fields as deprecated, check for all
access to those fields, change those to invoke the accessor methods, then
merge the class, then simplify the API.

Well, in C++, you could pretty easily do something like
this:

class Mergedtoken {
public:
int beginColumn, endColumn;
int &startColumn;

MergedToken() : startColumn(beginColumn) {}
};

This produces essentially the same effect as you'd be
hoping to get via the accessor functions -- but without
the ugly syntax.

I'll admit I've never had to try this with Java, so I'm
not _sure_ its references will support this like C++
does, but offhand I can't think of any particularly good
reason they shouldn't.

 

[Noah Roberts]

Unfortunately, the meaning of the term "reference" and "pointer" is
language-dependent. Java certainly does not have references in the C++
sense. All Java identifiers are used to designate distinct variables;
you never have two different variable names that both mean the same
thing.

Really?

class Y
{
A a;
public:
set_a(A an_a) { a = an_a; }
};

class Z
{
A a;
public:
set_a(A an_a) { a = an_a; }
};

....
Y y = new Y();
Z z = new Z();
A a = new A();

y.set_a(a);
z.set_a(a);
....

How about a less complex example...

A a = new A();
A a2 = a;

Are you saying all of those a's are different in java? It has been
quite a while since I last used it but it seems to me that they are all
the same instance. That would make C++ references and Java references
pretty close to the same thing.

 

[Oliver Wong]

How about a less complex example...

A a = new A();
A a2 = a;

Are you saying all of those a's are different in java? It has been
quite a while since I last used it but it seems to me that they are all
the same instance. That would make C++ references and Java references
pretty close to the same thing.

I'm going to avoid using the term "reference" and "pointer" in my
explanation here of Java's behaviour, and use a slightly different example
which will hopefully be more clear:

Integer a1 = new Integer(5);
Integer a2 = a1;

"a1", and "a2" are two different local variables which point to some
instance of Integer. They are both pointing to the same instance of Integer.
If, later on, you assign a different instance of Integer to "a1", "a2" will
still point to the old instance of Integer. So, for example, if you add the
following line:

a1 = new Integer(42);

then "a1" will now point to an Integer object which conceptually represents
the platonic concept of the number 42, while "a2" will still point to the
old Integer object which conceptually represents the platonic concept of the
number 5.

My understanding is that in C++, if you changed "a1" in that manner, and
if "a2" were a reference, then "a2" would also be updated to point to 42,
and not to 5.

- Oliver