next »

[BorisTheBrave]

You've missed an important difference between encapsulating properties (i.e. ones with trivial getters and setters) and public members.
With the latter, I can take the address of it, and use that pointer wherever I feel fit. Retrofitting a public member to a property is not just a (tedious) matter of adding brackets and keywords - it can sometimes be actually impossible if the address is taken and used elsewhere.
So it makes sense that properties are syntactically different from members - unlike most languages they have different semantics.  Please, don't start out with public members unless you really mean it.

C++ can be an incredibly terse language in places - but class definitions are definitely not one of them. It's just one of these things I guess.

You can alleviate this with macros, though I'm not sure I'd recommend it. Try the following, altering to taste.

Code:

#define PROPERTY(type, var) \
private: \
  type m_##var; \
public: \
  type var() { return m_##var; } \
  void var(type t) { m_##var = t; }

I prefer getVar, setVar, but the capitalization is annoying to do in macros.

When it comes to customizing your code later, you can replace the macro with actual code. Also note that the getter and setter here are inlined meaning it has the same performance as a public member variable. I hope that make people feel better about the slight pain of using properties from the start.

[muku]

You've missed an important difference between encapsulating properties (i.e. ones with trivial getters and setters) and public members.
With the latter, I can take the address of it, and use that pointer wherever I feel fit. Retrofitting a public member to a property is not just a (tedious) matter of adding brackets and keywords - it can sometimes be actually impossible if the address is taken and used elsewhere.

C# has properties, but no pointers (yeah, unsafe code, I know, but it's hardly relevant). I don't know if Java has properties yet, but it definitely has no pointers. D has properties and pointers, but the latter are really de-emphasized in the language. C++ has pointers, but no properties. So, in short, it's a mostly moot point because I can't think of a major language which uses both heavily. (Probably for a good reason: once you support properties, you are working at a higher level of abstraction with which low-level details like pointers don't play well.)

Besides, I would think it extremely bad design to take a pointer to a class member outside of that class unless you have a very good reason for it. The reason precisely being that it breaks encapsulation. Better keep a reference to the class itself around and access its members the way they're supposed to be.

From a purely OOD standpoint, there is no semantic difference between a public member variable and a getter/setter pair. Something like "foo.bar = 42" is just a message to the object foo to set its bar attribute to 42; how the class deals with that internally is just an implementation detail and should be of no concern to the client code.

[Average Software]

I had to learn a little C# for a job, and I have to admit that I just don't get properties.

You end up writing basically the same amount of code, just to save yourself a couple of keystrokes per use.  I don't see anything in any of the use cases that you couldn't do with plain old getters and setters.  Am I just totally missing something here?

Objective C properties seem a little more useful, since the compiler writes them for you, and you can give them attributes like atomic.  This makes sense to me, because now I don't have to write the getters and setters for the simple cases.

Code:

@interface SomeClass : NSObject
{
    int some_member;
}

@property (atomic, readonly) int some_member;

@end

@implementation SomeClass

// Write the property for me.
@synthesize some_member;
@end

Does C# do anything like this, or are the properties really just an extremely minor syntactic convenience?

Now if C# had real templates, properties would be awesome, since you could refer to data members and properties with the same generic syntax.  That's the only real purpose for them I can think of, and you can't do that.

[Alex May]

Actually I believe one can perfectly readily use pointers in C#, it is just that it's not 'done'. I seem to recall this from some msdn thing I read somewhere. I haven't checked up on it.

[Glaiel-Gamer]

I had to learn a little C# for a job, and I have to admit that I just don't get properties.

You end up writing basically the same amount of code, just to save yourself a couple of keystrokes per use.  I don't see anything in any of the use cases that you couldn't do with plain old getters and setters.  Am I just totally missing something here?

In flash at least, if you write a getter and setter that deals with basic types, it'll automatically let you do += -= etc on it. Like I have a vector class with a length getter/setter (but no stored length value), and I can do length += 5 and it works as you'd think its done.

[Mikademus]

<language_minutae>

I don't know if Java has properties yet, but it definitely has no pointers.

Correction: Java has ONLY pointers and no proper references (as C++ has) though Sun named them the other way around and used the dot as the pointer dereference operator, and forbids user initialisation to NULL. Put it like this, if Java had only proper references, you wouldn't have to check for null pointer exceptions.
</>

[muku]

<language_minutae>

I don't know if Java has properties yet, but it definitely has no pointers.

Correction: Java has ONLY pointers and no proper references (as C++ has) though Sun named them the other way around and used the dot as the pointer dereference operator, and forbids user initialisation to NULL. Put it like this, if Java had only proper references, you wouldn't have to check for null pointer exceptions.
</>

If you can't do arithmetic on it, it ain't a pointer

[BorisTheBrave]

Java doesn't have references or pointers as C++ would know them. I believe the docs call them references. The accurate statement would be to say Java references have pointer semantics (i.e. they behave as a pointer would - never copying the underlying object involved). You cannot say Java has pointers as that would mean you could have pointers to pointers and pointer arithmetic, which you cannot (boxing is different again). A quick google shows you can do these things in C#, so those are legitimate pointers.

BTW another factor of properties that trips me up all the time is the following:
myObject.position.x += 5;
Just doesn't do what you'd think it does. Or worse, in languages without const correctness, it does do what you think it does, until someone changes the getter and setter to something more complicated, and it breaks.
Yet another reason why it is rarely safe to refactor public members into properties when you really meant a property all along.

[Mikademus]

If you can't do arithmetic on it, it ain't a pointer

Actually you're wrong. Java has normal pointers. However, the language prohibits (imposes restrictions) on certain faculties, like assignment to NULL, pointers to pointers and pointer arithmetic. The "." and calling it "references" all have to do with marketing.

[muku]

Actually you're wrong.

[Movius]

I set things to NULL in java all the time back in the day, what fun it was.

[Shuger]

By definition pointer is a variable holding some memory address, who knows what "pointers" in java hold. It can be an index of object or whatever, please remember java does not compile to machine code but only to another form that runs on virtual machine. Still in semantic use, they are very similar but i don't think they should be called pointers since (as someone already said) you can't do any arithmetic on it and there are some serious reasons for that.

[Average Software]

By definition pointer is a variable holding some memory address, who knows what "pointers" in java hold. It can be an index of object or whatever, please remember java does not compile to machine code but only to another form that runs on virtual machine. Still in semantic use, they are very similar but i don't think they should be called pointers since (as someone already said) you can't do any arithmetic on it and there are some serious reasons for that.

This whole Java reference/pointer argument has been debunked numerous times.

The Java language specification says that references are in fact pointers.  Refer to section 4.3.1.

[muku]

The Java language specification says that references are in fact pointers.

So are C++ references. The operations you can perform on them are just severely restricted. I don't see the difference.

[Average Software]

The Java language specification says that references are in fact pointers.

So are C++ references. The operations you can perform on them are just severely restricted. I don't see the difference.

Not necessarily.  The C++ language standard specifies the behavior of references, but says nothing of their implementation.  A compiler could implement them as something unrelated to pointers entirely, and still be conforming.  On the other hand, the Java spec explicitly states that references are pointers.  That's an important difference.

[muku]

How does that matter? The C++ standard specifies exactly what I can do with a reference, and those operations are a strict subset of those I can perform on a pointer.

How else can a reference be implemented if not via a pointer? Can you show me a compiler which does that?

[Average Software]

How does that matter? The C++ standard specifies exactly what I can do with a reference, and those operations are a strict subset of those I can perform on a pointer.

Not true.  A reference has exactly one operation, and that is binding.  A pointer does not have this operation.  Pointers have assignment which is a different operation.  Assignment involves a value.  Binding does not.  Once a reference is bound, it takes on the type it was bound to.  From a language semantic perspective it is completely unrelated to a pointer.

How else can a reference be implemented if not via a pointer? Can you show me a compiler which does that?

I don't know how else it could be implemented, but that's completely irrelevant.  It's an implementation detail, and that's all that matters.  Assuming that a reference is a pointer is no different than assuming an int is four bytes.  You might get away with it 99% of the time, but it's still not a safe assumption to make.

[muku]

I think you're splitting hairs. Binding a reference is just another name for the analogous operation of assigning something to a pointer. Semantically, it's identical. Sure, there are lots of constraints (binding can only and must be done when a reference is created, you can't change the object a reference is bound to, etc), but it's still a strict subset.

Please explain to me how binding a reference is semantically different from assigning to a pointer.

[BorisTheBrave]

Ok, I was with you before muku, but you're overstepping now. binding a reference (in C++) is semantically different as you cannot "bind" to null.

Can we stop arguing about this, we are getting lost in semantics. Java references, C++ pointers and references are all different, but similar to each other in certain ways. What you call them and how they are implemented is irrelevant.

[muku]

Ok, I was with you before muku, but you're overstepping now. binding a reference (in C++) is semantically different as you cannot "bind" to null.

That's part of the constraints I was talking about. Everything you can do with a reference, you can do with a pointer, but not vice versa.

Can we stop arguing about this, we are getting lost in semantics. Java references, C++ pointers and references are all different, but similar to each other in certain ways. What you call them and how they are implemented is irrelevant.

This whole discussion feels really dumb, conceded, but Average Software seems to be trying to make a point which I just don't get, and I'd really like to know what he's on about. Maybe it would help to define the terms in question; problem is, every language seems to use them differently.