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.
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.
 



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.
 



 
 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 "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
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 "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  


 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.


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  


-Steve
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  


 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.


 
 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  

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








 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.


 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


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








 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.


 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


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








 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.


 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


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








 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.


 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


 -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 =


reason make it property_asdasdasd_a instead of property_a.

 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.



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.


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
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 reply 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
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 reply Sjoerd van Leent <svanleent gmail.com> writes:
Dimitar Kolev Wrote:



ambiguities of calling a function or a property with the same names.


I understand your idea, but it is contrary to the common understanding that a
property is a replacement of a field. As thus, from the users perspective, a
property should look and act the same as a field.

The this rules out another symbol.
Jul 31 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Sjoerd van Leent wrote:

 I understand your idea, but it is contrary to the common
 understanding that a property is a replacement of a field. As thus,
 from the users perspective, a property should look and act the same
 as a field.
 
 The this rules out another symbol.


Unless fields use the same new symbol.


-- 
Rainer Deyke - rainerd eldwood.com
Jul 31 2009
parent reply Sjoerd van Leent <svanleent gmail.com> writes:
Rainer Deyke Wrote:


 Sjoerd van Leent wrote:

 I understand your idea, but it is contrary to the common
 understanding that a property is a replacement of a field. As thus,
 from the users perspective, a property should look and act the same
 as a field.
 
 The this rules out another symbol.


 
 Unless fields use the same new symbol.
 
 
 -- 
 Rainer Deyke - rainerd eldwood.com


Yes, but won't that reintroduce the problems that are already available?
Jul 31 2009
parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Sjoerd van Leent wrote:


 The this rules out another symbol.


 
 Unless fields use the same new symbol.


 Yes, but won't that reintroduce the problems that are already available?




-- 
Michiel Helvensteijn
Jul 31 2009