www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - struct encapsulation

reply alex <alexibu.nospamplease mac.com> writes:
This code compiles - I don't think it should.
If b is a private member of A then why can I change it outside the class ?

struct A
{
private:
	int b;
};


int main()
{
	A a;
	a.b = 10;

	return 0;
}
Feb 19 2007
next sibling parent alex <alexibu.nospamplease mac.com> writes:
alex Wrote:

 This code compiles - I don't think it should.
 If b is a private member of A then why can I change it outside the class ?
 
 struct A
 {
 private:
 	int b;
 };
 
 
 int main()
 {
 	A a;
 	a.b = 10;
 
 	return 0;
 }

The code compiles when the accessing code is in the same module, otherwise it fails as expected. Sorry I misunderstood the meaning of private. Alex
Feb 19 2007
prev sibling parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
On Mon, 19 Feb 2007 21:18:05 -0500, alex wrote:

 This code compiles - I don't think it should.
 If b is a private member of A then why can I change it outside the class ?
 
 struct A
 {
 private:
 	int b;
 };
 
 
 int main()
 {
 	A a;
 	a.b = 10;
 
 	return 0;
 }

I see that you have solved your problem, but I have some thought on struct encapsulation. Imagine a struct like: struct angle { float degrees; } Now imagine we write a lot of code using angle: angle a1; a1.degrees= 60.0; ... writefln(a1.degrees); and then we need to refactor angle to use radians We change angle to class angle { float radians; public: float degrees(); // get degrees void degrees(float); //set degrees } But now we have to go trough all the code and change it to. angle a1; a1.degrees(60.0); ... writefln(a1.degrees()); What I think could be very useful is for D to automatic accept bar() and bar(type) as getter and setter for elements in structs and classes like. struct foo { type bar; } I know that we might like to keep the old way for backwards compatibility with c/c++ and D 1.0, but at last it will allow further generations to write maintainable code.
Feb 20 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Knud Soerensen wrote:
 On Mon, 19 Feb 2007 21:18:05 -0500, alex wrote:
 
 This code compiles - I don't think it should.
 If b is a private member of A then why can I change it outside the class ?

 struct A
 {
 private:
 	int b;
 };


 int main()
 {
 	A a;
 	a.b = 10;

 	return 0;
 }

I see that you have solved your problem, but I have some thought on struct encapsulation. Imagine a struct like: struct angle { float degrees; } Now imagine we write a lot of code using angle: angle a1; a1.degrees= 60.0; ... writefln(a1.degrees); and then we need to refactor angle to use radians We change angle to class angle { float radians; public: float degrees(); // get degrees void degrees(float); //set degrees } But now we have to go trough all the code and change it to. angle a1; a1.degrees(60.0); ... writefln(a1.degrees()); What I think could be very useful is for D to automatic accept bar() and bar(type) as getter and setter for elements in structs and classes like. struct foo { type bar; } I know that we might like to keep the old way for backwards compatibility with c/c++ and D 1.0, but at last it will allow further generations to write maintainable code.

Either A) I'm totally misunderstanding you, B) you're being funny or C) you're not aware of property syntax: http://www.digitalmars.com/d/property.html#classproperties --bb
Feb 20 2007
prev sibling parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
On Tue, 20 Feb 2007 17:23:30 +0900, Bill Baxter wrote:

 Knud Soerensen wrote:
 On Mon, 19 Feb 2007 21:18:05 -0500, alex wrote:
 
 This code compiles - I don't think it should.
 If b is a private member of A then why can I change it outside the class ?

 struct A
 {
 private:
 	int b;
 };


 int main()
 {
 	A a;
 	a.b = 10;

 	return 0;
 }

I see that you have solved your problem, but I have some thought on struct encapsulation. Imagine a struct like: struct angle { float degrees; } Now imagine we write a lot of code using angle: angle a1; a1.degrees= 60.0; ... writefln(a1.degrees); and then we need to refactor angle to use radians We change angle to class angle { float radians; public: float degrees(); // get degrees void degrees(float); //set degrees } But now we have to go trough all the code and change it to. angle a1; a1.degrees(60.0); ... writefln(a1.degrees()); What I think could be very useful is for D to automatic accept bar() and bar(type) as getter and setter for elements in structs and classes like. struct foo { type bar; } I know that we might like to keep the old way for backwards compatibility with c/c++ and D 1.0, but at last it will allow further generations to write maintainable code.

Either A) I'm totally misunderstanding you, B) you're being funny or C) you're not aware of property syntax: http://www.digitalmars.com/d/property.html#classproperties --bb

I seems to remember something about this property feature but I got it reversed in my test, so it didn't work. This is how it goes when one tries to post on newsgroups early in the morning after a night without sleep :-)
Feb 20 2007