Skip to main content

A few thoughts from a C# developer converting to Java (as well)

15 replies [Last post]
zosoo7
Offline
Joined: 2004-12-14
Points: 0

Hello all, I'm a former/still a C# developer who is becoming a full time Java developer (large Java shop!!!). I have a couple insights. Some people argue this because they say that OO should be objects communicating via methods, but I think it would be nice if Java had "properties" (as C# has) for their getters/setters instead of seperate methods , it's much easier to code with. Also, and this is just a naming convention issue, I would really love it if interface names would use the capital I naming convention, IPersistent for example, the benefits of doing this are obvious. Nice going with enums in 1.5, that was long needed.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
zosoo7
Offline
Joined: 2004-12-14
Points: 0

Yes, that is the one thing that sucks (but it's great), is that backwards compadibility will always, always have to be maintained, the only other way around it which would be some major cowboy coding would be to have the newly named interface extend the corresponding interface and not add any stubs.

interface ISomeInterface extends SomeInterface
{
}

I have been invited onto an open source project, and we are using the I convention and it saves us a ton of confusion. I guess what it comes down to with my thoughts are out of laziness!!! Not wanting to look at doc to see if a particular class is an interface, and not wanting to check my code completion menu if a get method is also writable, hehe. So let me ask everybody this, since Java is always going to support backwars compatibility for all time and eternity, how is it ever going to mature into a language that doesn't have a lot of pitfalls?

jwenting
Offline
Joined: 2003-12-02
Points: 0

Bad idea...

If you really want this you can even now use public datamembers (which is how it's probably implemented in C# as well if you look under the hood).

In Delphi you can define something as a property.
All that does is allow you to call it by its name, but under the hood a function with a specific signature that you need to provide is called instead.
Syntactic sugar really, nice for IDEs but just confusing otherwise (now was that a public datamember, a property, or what that I see there).

ahmetaa
Offline
Joined: 2003-06-21
Points: 0

Hello,
Most IDE's support automatic getter-setter creation (Eclpse, IDEA etc). Also they have code folding which makes the getter-setter clutter less. So, i think with the help of those tools simplicity of using getter setter overcomes the properties learning curve.
For the interface naming, i do not think users should be forced for this. To me, List - ArrayList pair is cleaner then IList - ArrayList. IDE's warn you and inform you for usage of Interfaces anyway.. So, i think those issues should not really be a first priority IMHO.

mgrev
Offline
Joined: 2003-08-12
Points: 0

Doesn't properties fail the Java idiom 'What you see is what you get'?

If i see x.y = 10.0 I'd rather that was actually the case... With properties can't y become something else, say because of a constraint or some other logic?

Cheers,
Mikael Grev

tackline
Offline
Joined: 2003-06-19
Points: 0

How often do you use expressions such as x.y? Hopefully most classes at least use getters and setters pretending to be encapsulation. So when you see x.y = 10; or even x.Y = 10; read it as x.y(10);.

But -1 for properties, and +1 for encouraging encapsulation.

saintjohn
Offline
Joined: 2004-10-25
Points: 0

"When in Rome, do as Romans do"

I don't understand people who came from other languages and try to change Java, which is foreign for them. If you like generics, multi-inheritance, operator overloading, properties and so on, why don't you go back to your C#, C++,... ?
Why are you trying to ruin one of the best nowaday languages?

zosoo7
Offline
Joined: 2004-12-14
Points: 0

Well, if you don't ever want to "change" a language, than it is never going to progress and fix it's shortcomings. If you truly believe that, then I assume you think we should all be on jdk 1.0? What do you think about depricated methods? I'd venture to say that there aren't very many people out there whow would say the the 1.5 additions were "ruining" a language.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

There are still people who want to see all declaration in identifier.
- Some want interfaces to begin with 'I',
- others want private variables to begin with underscore,
- member variables to start with 'm_', or
- they want int*, str*, bool* prefixes...

This is all wrong. all this stuff is intended to be in declaration and should not be duplicated in identifiers.
But even if it was not wrong, there can be so many code convention options that you simply cannot satisfy all of them.

+1 for properties, I miss them so much.
related proposal is here: http://forums.java.net/jive/thread.jspa?threadID=104

cowwoc
Offline
Joined: 2003-08-24
Points: 0

-1

It is far cheaper to have the IDE generate getter/setter methods for your properties. Extend the Java language for this is overkill. Furthermore, I think you people are nitpicking over something that really isn't such a big deal. I personally don't see myself using such a feature often or at all.

Gili

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

1) how can it be cheaper? if you need getters/setters often, every IDE must support this to be useful. it is much more cheaper to have this supported by language

2) you never create data or value objects? you never maintain them?

tsinger
Offline
Joined: 2003-06-10
Points: 0

Although I'm not Gili, I'm with him/her.

> 1) how can it be cheaper? if you need getters/setters
> often, every IDE must support this to be useful. it
> is much more cheaper to have this supported by
> language

No, only your IDE needs to support it. And mine does.

Why raise the level for newbies (not you, not me), which need to learn yet another language trick to achive something, which can be achieved with existing language features?

> 2) you never create data or value objects? you never
> maintain them?

No. Ever heard about code-generation? If you have dumb data objects, which only have primitive getters/setters, you can generate them from XML using XSLT, for instance.

Tom

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

> Hello all, I'm a former/still a C# developer who is
> becoming a full time Java developer (large Java
> shop!!!). I have a couple insights. Some people argue
> this because they say that OO should be objects
> communicating via methods, but I think it would be
> nice if Java had "properties" (as C# has) for their
> getters/setters instead of seperate methods , it's
> much easier to code with. Also, and this is just a
> naming convention issue, I would really love it if
> interface names would use the capital I naming
> convention, IPersistent for example

I agree with subanark plus IPersistent smacks of Hungrian notations which has been generally agreed upon as being a problematic naming convention.

dgreenbean
Offline
Joined: 2003-12-08
Points: 0

+1 on the properties. This would not only make a lot of code nicer, it would make beans much easier to work with. Some other people have gotten into the game of recommending this in the past, I believe. The only problem is that it would introduce a lot of complexity to the core language, and I am not sure if this is worth it. I am usually pro adding language features if they will be of serious benefit, but I am not convinced that this is one of them.

-1 on the interface naming. First off, there's no way all of the current interfaces could ever be changed to follow this convention. Due to this restriction, implementing the convention on new interfaces would simply confuse the matter further, having many following the convention and many not. This might have been worthwhile at the birth of the language, but I would also disagree with that, as I would rather let the code and javadocs separate interfaces from classes than have their names do it.

Agreed with enums and all the other greatness of 1.5

subanark
Offline
Joined: 2004-11-26
Points: 0

I disagree with having properties used without the function call decoration.

Mainly since it is easier to tell if you are actually using putField or calling a function.
1. An API cannot simply change a field into a property, even though it is get/set the same way in code, changing this will cause incompadibilities.
2. For security reasons when a code block synchronizes on an object, it can assure its self that setting/getting fields will not change in an unexpected way. If property syntax is allowed then any time you use an object in a secure way you would have to ensure that any fields you are use a get are not in fact virtual properties. Since hotile code can override this property and peform unexpected tasks at that point.

zosoo7
Offline
Joined: 2004-12-14
Points: 0

I am am a bit confused on your second point. The private members are still hidden whether it be accessed through property syntax vs. method syntax. Wouldn't you have to make sure that the get and set methods aren't overridable as well?
I guess I'm also not sure how it would cause incompatibilities? All current code that accesses private members through getVariableName()/setVariableName() would still work, but you would instead be adding the ability to have:

private int someVar;

public int SomeVar
{
get
{
return(someVar);
}
set
{
someVar = value;
}
}

Unless you are talking about incompatibilites at the core language level, which I don't know much about :).