www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Yet a new properties proposal

reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Okay correct me if I am wrong but why not make properties like that:

class a
{
     int #a;
}

The compiler can expand this to:

int property_a(int new_a)
{
     return this.a = new_a;
}

int property_a()
{
      return this.a;
}

If you think that somebody is going to use property_a for whatever other reason
make it property_asdasdasd_a instead of property_a.

Then just call it a#a = 3 or b = a#a =3.

Correct me if I am wrong.
Jul 29 2009
next sibling parent KennyTM~ <kennytm gmail.com> writes:
Dimitar Kolev wrote:
 Okay correct me if I am wrong but why not make properties like that:
 
 class a
 {
      int #a;
 }
 
 The compiler can expand this to:
 
 int property_a(int new_a)
 {
      return this.a = new_a;
 }
 
 int property_a()
 {
       return this.a;
 }
 
 If you think that somebody is going to use property_a for whatever other
reason make it property_asdasdasd_a instead of property_a.
 
 Then just call it a#a = 3 or b = a#a =3.
 
 Correct me if I am wrong.

a#line ....
Jul 29 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 29 Jul 2009 13:20:06 -0400, Dimitar Kolev  
<DimitarRosenovKolev hotmail.com> wrote:

 Okay correct me if I am wrong but why not make properties like that:

 class a
 {
      int #a;
 }

 The compiler can expand this to:

 int property_a(int new_a)
 {
      return this.a = new_a;
 }

 int property_a()
 {
       return this.a;
 }

 If you think that somebody is going to use property_a for whatever other  
 reason make it property_asdasdasd_a instead of property_a.

 Then just call it a#a = 3 or b = a#a =3.

 Correct me if I am wrong.

I don't see what advantages this has over other proposals. What is wrong with a.a such that we have to resort to a#a? -Steve
Jul 29 2009
parent reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Steven Schveighoffer Wrote:

 I don't see what advantages this has over other proposals.  What is wrong  
 with a.a such that we have to resort to a#a?
 
 -Steve
 

People are crying over compilers not know which is a property and which is not.
Jul 29 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Dimitar Kolev wrote:
 Steven Schveighoffer Wrote:
 
 I don't see what advantages this has over other proposals.  What is wrong  
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and which is not.

Actually, one of the major "features" of properties is that any field can be changed into a property without any changes to existing code. If you're looking for an unused symbol, is likely a better choice than #.
Jul 29 2009
parent reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Robert Fraser Wrote:

 Dimitar Kolev wrote:
 Steven Schveighoffer Wrote:
 
 I don't see what advantages this has over other proposals.  What is wrong  
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and which is not.

Actually, one of the major "features" of properties is that any field can be changed into a property without any changes to existing code. If you're looking for an unused symbol, is likely a better choice than #.

I do not care what symbol it is as long as it is not used before and that you can spot it from a distance. When you see a.a = 3 and a a = 3 you immediately know which is what without having to look for the definition of a in the class hierarchy. Walter did this already with the templates !(. You can mistake a!(a) with a(!a) but who cares. !( is still understandable enough. Way better than the unambiguous <>.
Jul 29 2009
parent Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Dimitar Kolev Wrote:

 Robert Fraser Wrote:
 
 Dimitar Kolev wrote:
 Steven Schveighoffer Wrote:
 
 I don't see what advantages this has over other proposals.  What is wrong  
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and which is not.

Actually, one of the major "features" of properties is that any field can be changed into a property without any changes to existing code. If you're looking for an unused symbol, is likely a better choice than #.

I do not care what symbol it is as long as it is not used before and that you can spot it from a distance. When you see a.a = 3 and a a = 3 you immediately know which is what without having to look for the definition of a in the class hierarchy. Walter did this already with the templates !(. You can mistake a!(a) with a(!a) but who cares. !( is still understandable enough. Way better than the unambiguous <>.

Ambiguous I meant sorry.
Jul 29 2009
prev sibling parent reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 14:59:38 -0400, Dimitar Kolev  
 <DimitarRosenovKolev hotmail.com> wrote:
 
 Steven Schveighoffer Wrote:

 I don't see what advantages this has over other proposals.  What is  
 wrong
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and which is not.

At definition time, not usage time. I want the usage to be identical to fields, otherwise, it's not as seamless. This makes an important difference for generic code.

What if the compiler just expanding this to well inlining. So a#a = 3 would just means a.a = 3 just that the compiler will have easier time understanding this. And a#b#c would just expand to a.b.c it is just that you can without any doubt see in the code that a#b#c is actually a property not a function. The expansion can come before the generic code. Not to mention that then there will be no confusion what writefl = 3 is. A function called without the parentheses and you won't have to track what that is in the definition of the class.
Jul 29 2009
parent reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 17:46:39 -0400, Dimitar Kolev  
 <DimitarRosenovKolev hotmail.com> wrote:
 
 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 14:59:38 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 I don't see what advantages this has over other proposals.  What is
 wrong
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and

 is not.

At definition time, not usage time. I want the usage to be identical to fields, otherwise, it's not as seamless. This makes an important difference for generic code.

What if the compiler just expanding this to well inlining. So a#a = 3 would just means a.a = 3 just that the compiler will have easier time understanding this.

If you specify a property at definition by doing int#a, then why do you also need to specify it's a property when calling it? And if it's not necessary, then your proposal is no different than adding a keyword. On those merits, it's fine with me if people think int #a is better than property int a, but I absolutely don't want to have to modify my code to call properties using a #. -Steve

Since when is D 2.0 frozen so that we have to take care of old D 2.0 code. This is not an accusation just a reminder. Hope ware not going for the mistakes of C++.
Jul 29 2009
next sibling parent reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 18:07:19 -0400, Dimitar Kolev  
 <DimitarRosenovKolev hotmail.com> wrote:
 
 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 17:46:39 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 14:59:38 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 I don't see what advantages this has over other proposals.  What  




 wrong
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and

 is not.

At definition time, not usage time. I want the usage to be


 fields, otherwise, it's not as seamless.  This makes an important
 difference for generic code.

What if the compiler just expanding this to well inlining. So a#a = 3 would just means a.a = 3 just that the compiler will have easier time understanding this.

If you specify a property at definition by doing int#a, then why do you also need to specify it's a property when calling it? And if it's not necessary, then your proposal is no different than adding a keyword. On those merits, it's fine with me if people think int #a is better than property int a, but I absolutely don't want to have to modify my code to call properties using a #. -Steve

Since when is D 2.0 frozen so that we have to take care of old D 2.0 code. This is not an accusation just a reminder. Hope ware not going for the mistakes of C++.

I understand that D2 is not frozen. I don't want to call properties with a#b instead of a.b in D2, D3, or even D4, unless you can show that it provides some benefit. From what I can tell, it does not. Sorry. I don't mean to be harsh, but I don't think your proposal makes any sense at all. Maybe you can answer my first question -- why do you need to call a property with a#b when you can call it with a.b? -Steve

class plane { bool fly = false; bool fly() { if (fly == false) return false; // code for flying. // If it breaks for some reason return false; // else return that everything is okay. return true; } } If I am missing something please say but is this not ambiguous now? Is the function called or the property?
Jul 29 2009
parent Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Jarrett Billingsley Wrote:

 On Wed, Jul 29, 2009 at 6:20 PM, Dimitar
 Kolev<DimitarRosenovKolev hotmail.com> wrote:
 class plane
 {
    bool fly = false;
    bool fly()
    {
         if (fly == false) return false;

         // code for flying.
         // If it breaks for some reason
         return false;

         // else return that everything is okay.

         return true;
    }
 }

 If I am missing something please say but is this not ambiguous now?
 Is the function called or the property?

Neither. The code won't compile, because unlike Java, you are not allowed to have both a field and a method of the same name.

Now you can be allowed. And Andrei can keep the empty and no body will be insisting of isEmpty anymore.
Jul 29 2009
prev sibling next sibling parent reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 18:07:19 -0400, Dimitar Kolev  
 <DimitarRosenovKolev hotmail.com> wrote:
 
 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 17:46:39 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 14:59:38 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 I don't see what advantages this has over other proposals.  What  




 wrong
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and

 is not.

At definition time, not usage time. I want the usage to be


 fields, otherwise, it's not as seamless.  This makes an important
 difference for generic code.

What if the compiler just expanding this to well inlining. So a#a = 3 would just means a.a = 3 just that the compiler will have easier time understanding this.

If you specify a property at definition by doing int#a, then why do you also need to specify it's a property when calling it? And if it's not necessary, then your proposal is no different than adding a keyword. On those merits, it's fine with me if people think int #a is better than property int a, but I absolutely don't want to have to modify my code to call properties using a #. -Steve

Since when is D 2.0 frozen so that we have to take care of old D 2.0 code. This is not an accusation just a reminder. Hope ware not going for the mistakes of C++.

I understand that D2 is not frozen. I don't want to call properties with a#b instead of a.b in D2, D3, or even D4, unless you can show that it provides some benefit. From what I can tell, it does not. Sorry. I don't mean to be harsh, but I don't think your proposal makes any sense at all. Maybe you can answer my first question -- why do you need to call a property with a#b when you can call it with a.b? -Steve

Different example: class plane { bool fly = false; bool fly() { if (fly == false) return false; // code for flying. // If it breaks for some reason return false; // else return that everything is okay. return true; } } class pilot { if (myPlane.fly) myPlane.fly; } So this becomes: class plane { bool fly = false; bool fly() { if ( fly == false) return false; // code for flying. // If it breaks for some reason return false; // else return that everything is okay. return true; } } class pilot { if (myPlane fly) myPlane.fly; }
Jul 29 2009
parent Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Dimitar Kolev Wrote:

Sorry I need an edit button. It is 12:30 a.m. here.

 Different example:
 
 class plane
 {
     bool fly = false;
     bool fly()
     {
          if (fly == false) return false;
 
          // code for flying.
          // If it breaks for some reason
          return false;
 
          // else return that everything is okay.
 
          return true;
     }
 }
 
 class pilot
 {
       if (myPlane.fly) 
          myPlane.fly;
 }
 
 So this becomes:
 
 class plane
 {
     bool  fly = false;
     bool fly()
     {
          if ( fly == false) return false;
 
          // code for flying.
          // If it breaks for some reason
          return false;
 
          // else return that everything is okay.
 
          return true;
     }
 }

class pilot { plane myPlane; plane myPlane() { myPlane = new plane(); } bool fly() { if ( myPlane == null) myPlane(); if ( myPlane fly == false) myPlane fly = true; myPlane.fly; } } By the way I do not care if you are harsh or not. I just want this resolved.
Jul 29 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Wed, 29 Jul 2009 18:07:19 -0400, Dimitar Kolev 
 <DimitarRosenovKolev hotmail.com> wrote:
 
 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 17:46:39 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 14:59:38 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 I don't see what advantages this has over other proposals.  




 wrong
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and

 is not.

At definition time, not usage time. I want the usage to be


 fields, otherwise, it's not as seamless.  This makes an important
 difference for generic code.

What if the compiler just expanding this to well inlining. So a#a = 3 would just means a.a = 3 just that the compiler will have easier time understanding this.

If you specify a property at definition by doing int#a, then why do you also need to specify it's a property when calling it? And if it's not necessary, then your proposal is no different than adding a keyword. On those merits, it's fine with me if people think int #a is better than property int a, but I absolutely don't want to have to modify my code to call properties using a #. -Steve

Since when is D 2.0 frozen so that we have to take care of old D 2.0 code. This is not an accusation just a reminder. Hope ware not going for the mistakes of C++.

I understand that D2 is not frozen. I don't want to call properties with a#b instead of a.b in D2, D3, or even D4, unless you can show that it provides some benefit. From what I can tell, it does not. Sorry. I don't mean to be harsh, but I don't think your proposal makes any sense at all. Maybe you can answer my first question -- why do you need to call a property with a#b when you can call it with a.b?

I agree. The whole point of properties is that they are largely interchangeable with fields. If that's not an issue, we might as well use a.b() and call it a day. Andrei
Jul 29 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Jul 29, 2009 at 10:20 AM, Dimitar
Kolev<DimitarRosenovKolev hotmail.com> wrote:
 Okay correct me if I am wrong but why not make properties like that:

 class a
 {
 =A0 =A0 int #a;
 }

 The compiler can expand this to:

 int property_a(int new_a)
 {
 =A0 =A0 return this.a =3D new_a;
 }

 int property_a()
 {
 =A0 =A0 =A0return this.a;
 }

 If you think that somebody is going to use property_a for whatever other =

 Then just call it a#a =3D 3 or b =3D a#a =3D3.

 Correct me if I am wrong.

The point is to be able to start with class Foo { int a; } and later change implementation or add access monitoring without affecting all the code that already acceesses Foo's .a field. So this should compile both before and after changing Foo.a from a field to a property: Foo x; x.a =3D 3; x.a +=3D 3; // ** writefln("x.a now %s", x.a); --bb ** this doesn't currently work with D when a() is a function, but it should= .
Jul 29 2009
parent Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Bill Baxter Wrote:

 The point is to be able to start with
 
 class Foo
 {
    int a;
 }
 
 and later change implementation or add access monitoring without
 affecting all the code that already acceesses Foo's .a field.
 So this should compile both before and after changing Foo.a from a
 field to a property:
 
 Foo x;
 x.a = 3;
 x.a += 3;  // **
 writefln("x.a now %s", x.a);
 
 --bb
 ** this doesn't currently work with D when a() is a function, but it should.

As long as there is a function called a inside that class there will be no way to call a.a without calling that function or calling that member value. You just need a special word for that. And what I am proposing is not a word but simple a character #. You want to start with: class a { int a; } but when I put class a { int b; int b() { return 3;} } there will be no way to distinguish between the two calls without the compiler being forced to call an error and yet again the user will have to change his/her code. Just make all properties accessed by # and you will save yourself the ambiguities of calling a function or a property with the same names.
Jul 29 2009
prev sibling next sibling parent reply language_fan <foo bar.com.invalid> writes:
Wed, 29 Jul 2009 13:20:06 -0400, Dimitar Kolev thusly wrote:

 Okay correct me if I am wrong but why not make properties like that:
 
 class a
 {
      int #a;
 }
 
 The compiler can expand this to:
 
 int property_a(int new_a)
 {
      return this.a = new_a;
 }
 
 int property_a()
 {
       return this.a;
 }
 
 If you think that somebody is going to use property_a for whatever other
 reason make it property_asdasdasd_a instead of property_a.
 
 Then just call it a#a = 3 or b = a#a =3.

This sounds excellent. This way the properties would work exactly like publicly available members by default, only a bit slower unless the compiler does optimizations. The only use case anyone will ever need..
Jul 29 2009
next sibling parent reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
language_fan Wrote:

 Wed, 29 Jul 2009 13:20:06 -0400, Dimitar Kolev thusly wrote:
 
 Okay correct me if I am wrong but why not make properties like that:
 
 class a
 {
      int #a;
 }
 
 The compiler can expand this to:
 
 int property_a(int new_a)
 {
      return this.a = new_a;
 }
 
 int property_a()
 {
       return this.a;
 }
 
 If you think that somebody is going to use property_a for whatever other
 reason make it property_asdasdasd_a instead of property_a.
 
 Then just call it a#a = 3 or b = a#a =3.

This sounds excellent. This way the properties would work exactly like publicly available members by default, only a bit slower unless the compiler does optimizations. The only use case anyone will ever need..

Where is the slow part when you have inline?
Jul 29 2009
parent Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
language_fan Wrote:

 Wed, 29 Jul 2009 16:01:33 -0400, Dimitar Kolev thusly wrote:
 
 Where is the slow part when you have inline?

What inline do I have? Are you suggesting that the keyword should be resurrected?

You are telling me that the dmd compiler can not inline implicitly the a#a syntax? Isn't there a -inline option in the compiler.
Jul 29 2009
prev sibling parent language_fan <foo bar.com.invalid> writes:
Wed, 29 Jul 2009 16:01:33 -0400, Dimitar Kolev thusly wrote:

 Where is the slow part when you have inline?

What inline do I have? Are you suggesting that the keyword should be resurrected?
Jul 29 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 29 Jul 2009 14:59:38 -0400, Dimitar Kolev  
<DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 I don't see what advantages this has over other proposals.  What is  
 wrong
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and which is not.

At definition time, not usage time. I want the usage to be identical to fields, otherwise, it's not as seamless. This makes an important difference for generic code.
Jul 29 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 29 Jul 2009 17:46:39 -0400, Dimitar Kolev  
<DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 14:59:38 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 I don't see what advantages this has over other proposals.  What is
 wrong
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and

 is not.

At definition time, not usage time. I want the usage to be identical to fields, otherwise, it's not as seamless. This makes an important difference for generic code.

What if the compiler just expanding this to well inlining. So a#a = 3 would just means a.a = 3 just that the compiler will have easier time understanding this.

If you specify a property at definition by doing int#a, then why do you also need to specify it's a property when calling it? And if it's not necessary, then your proposal is no different than adding a keyword. On those merits, it's fine with me if people think int #a is better than property int a, but I absolutely don't want to have to modify my code to call properties using a #. -Steve
Jul 29 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 29 Jul 2009 18:07:19 -0400, Dimitar Kolev  
<DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 17:46:39 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 On Wed, 29 Jul 2009 14:59:38 -0400, Dimitar Kolev
 <DimitarRosenovKolev hotmail.com> wrote:

 Steven Schveighoffer Wrote:

 I don't see what advantages this has over other proposals.  What  




 wrong
 with a.a such that we have to resort to a#a?

 -Steve

People are crying over compilers not know which is a property and

 is not.

At definition time, not usage time. I want the usage to be


 fields, otherwise, it's not as seamless.  This makes an important
 difference for generic code.

What if the compiler just expanding this to well inlining. So a#a = 3 would just means a.a = 3 just that the compiler will have easier time understanding this.

If you specify a property at definition by doing int#a, then why do you also need to specify it's a property when calling it? And if it's not necessary, then your proposal is no different than adding a keyword. On those merits, it's fine with me if people think int #a is better than property int a, but I absolutely don't want to have to modify my code to call properties using a #. -Steve

Since when is D 2.0 frozen so that we have to take care of old D 2.0 code. This is not an accusation just a reminder. Hope ware not going for the mistakes of C++.

I understand that D2 is not frozen. I don't want to call properties with a#b instead of a.b in D2, D3, or even D4, unless you can show that it provides some benefit. From what I can tell, it does not. Sorry. I don't mean to be harsh, but I don't think your proposal makes any sense at all. Maybe you can answer my first question -- why do you need to call a property with a#b when you can call it with a.b? -Steve
Jul 29 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Jul 29, 2009 at 6:20 PM, Dimitar
Kolev<DimitarRosenovKolev hotmail.com> wrote:
 class plane
 {
 =A0 =A0bool fly =3D false;
 =A0 =A0bool fly()
 =A0 =A0{
 =A0 =A0 =A0 =A0 if (fly =3D=3D false) return false;

 =A0 =A0 =A0 =A0 // code for flying.
 =A0 =A0 =A0 =A0 // If it breaks for some reason
 =A0 =A0 =A0 =A0 return false;

 =A0 =A0 =A0 =A0 // else return that everything is okay.

 =A0 =A0 =A0 =A0 return true;
 =A0 =A0}
 }

 If I am missing something please say but is this not ambiguous now?
 Is the function called or the property?

Neither. The code won't compile, because unlike Java, you are not allowed to have both a field and a method of the same name.
Jul 29 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 29 Jul 2009 18:33:29 -0400, Dimitar Kolev  
<DimitarRosenovKolev hotmail.com> wrote:

I'm not getting your example...

 Different example:

 class plane
 {
     bool fly = false;
     bool fly()
     {
          if (fly == false) return false;

          // code for flying.
          // If it breaks for some reason
          return false;

          // else return that everything is okay.

          return true;
     }
 }

 class pilot
 {
       if (myPlane.fly)
          myPlane.fly;
 }

 So this becomes:

 class plane
 {


Is this a property or a field? If it's a property, where is the code for the property? If it's a field, then.... um I have no idea what you are saying. Mark all fields with ?
     bool  fly = false;


This is a function or a property?
     bool fly()
     {
          if ( fly == false) return false;

          // code for flying.
          // If it breaks for some reason
          return false;

          // else return that everything is okay.

          return true;
     }
 }

class pilot { plane myPlane;

Huh? What are you doing here, there is no return value...
        plane myPlane()
        {
                myPlane = new plane();
        }

        bool fly()
        {
               if ( myPlane == null)
                     myPlane();

Does this use the field or the property of the plane? Or is there a field?
               if ( myPlane fly == false)
                    myPlane fly = true;

                myPlane.fly;
        }
 }

Still confused.... -Steve
Jul 30 2009