Thread overview
struct encapsulation
Feb 20, 2007
alex
Feb 20, 2007
alex
Feb 20, 2007
Knud Soerensen
Feb 20, 2007
Bill Baxter
Feb 20, 2007
Knud Soerensen
February 20, 2007
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;
}
February 20, 2007
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

February 20, 2007
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.
February 20, 2007
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
February 20, 2007
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 :-)