struct encapsulation

[Knud Soerensen]

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 :-)