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
parent reply 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
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