June 06, 2002
"Walter" <walter@digitalmars.com> wrote in news:admft7$22v7$2@digitaldaemon.com:

> 
> "Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CFE82EF.90305@ece.arizona.edu...
>> Of course this example is simple and could be replaced by simply using a public variable. But the important part is the property keyword. I don't know if that would make anything easier or not, but I really hope you can include this kind of properties syntax into D regardless of whether it uses a special keyword or not. Just an idea...
> 
> Unfortunately, I don't see how that will resolve the particular problem with the confusion between f.a and f.a().
> 
> 

Couldn't using the property attribute disallow
the use of the name as a function.

property int width()
{
  return theWidth;
}

f.width works but f.width() is illegal unless...


property int delegate(int)() dg;
{
  return theDelegate;
}

In which case f.dg() works because the dg property
returns a function pointer
June 06, 2002
On Wed, 5 Jun 2002 17:26:31 -0700, "Walter" <walter@digitalmars.com> wrote:
> 
> "Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CFE82EF.90305@ece.arizona.edu...
> > Of course this example is simple and could be replaced by simply using a public variable. But the important part is the property keyword. I don't know if that would make anything easier or not, but I really hope you can include this kind of properties syntax into D regardless of whether it uses a special keyword or not. Just an idea...
> 
> Unfortunately, I don't see how that will resolve the particular problem with the confusion between f.a and f.a().
> 

I doubt that this is news but:

  UNIFORM ACCESS PRINCIPLE
All services offered by a module should be available through a
uniform notation, which does not betray whether they are implemented
through storage or through computation.
--- Bertrand Meyer

The issue is not variables (f.a) versus functions (f.a())  but features which do
or do not take parameters.

f.a and f.a() should be  the same thing, regardless of what 'a' is.




June 06, 2002
"Walter" <walter@digitalmars.com> wrote in news:adgp6f$2e9o$1@digitaldaemon.com:

> 
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:adcg51$2imn$1@digitaldaemon.com...
>> If it seems hard to implement them in the way documented in the
>> reference, then
>> maybe try the C# approach?
>>
>>     class Button
>>     {
>>         private int m_width;
>>         public int width
>>         {
>>             get
>>             {
>>                 return m_width;
>>             }
>>             set
>>             {
>>                 m_width = value;
>>                 repaint();
>>             }
>>         }
>>     }
> 
> I'm not too thrilled with that approach. It just seems like a lot of syntax for not much of nothing <g>.

I like Pavel's syntax best but how about.

class Button
{
  private int m_width;

  public int get:width()
  {
    return m_width;
  }

  public void set:width(int val)
  {
    m_width = val;
  }
}

or why do you even need the function syntax

class Button
{
  private int m_width;

  public int get:width
  {
    return m_width;
  }

  public void set:width
  {
    m_width = value;
  }
}
June 06, 2002
I agree..  I always considered the () superfluous.  If I wanted the address of a function I'd use &foo.

I don't see why the property private variable and the property externally visible name should be the same.  Anywhere else it's a redeclaration and is illegal.

Sean

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1023338484@bose...
> On Wed, 5 Jun 2002 17:26:31 -0700, "Walter" <walter@digitalmars.com>
wrote:
> >
> > "Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CFE82EF.90305@ece.arizona.edu...
> > > Of course this example is simple and could be replaced by simply using a public variable. But the important part is the property keyword. I don't know if that would make anything easier or not, but I really hope you can include this kind of properties syntax into D regardless of whether it uses a special keyword or not. Just an idea...
> >
> > Unfortunately, I don't see how that will resolve the particular problem
with
> > the confusion between f.a and f.a().
> >
>
> I doubt that this is news but:
>
>   UNIFORM ACCESS PRINCIPLE
> All services offered by a module should be available through a
> uniform notation, which does not betray whether they are implemented
> through storage or through computation.
> --- Bertrand Meyer
>
> The issue is not variables (f.a) versus functions (f.a())  but features
which do
> or do not take parameters.
>
> f.a and f.a() should be  the same thing, regardless of what 'a' is.



June 16, 2002
"Jonas" <jonas.vermeulen@student.kuleuven.ac.be> wrote in message news:adcg8g$2j06$1@digitaldaemon.com...
>
> > The packages are implemented. The templates are not defined and are for version 2 of the language. The property gettors/settors are turning out
to
> > be a problem, they may just get dumped.
> >
> >
>
> Though they  are not necessary, I would find it a big loss for D it won't
be
> implemented. See the messages about "Any modern language should include properties" and others about them. They are a real pro for D!!
>
> BTW: I agree with some that Delphi is clearer in its syntax.
>


The Delphi syntax works quitte well and is proven
in practice...Why not use it?

MyClass = class
public
   MyProp: integer; read GetMyProp write SetMyProp;

private
   function GetMyProp: integer;
   procedure SetMyProp (Value: integer);
end;

// ...

function MyClass.GetMyProp: integer;
begin
  Result := MyProp;
end;

procedure MyClass.SetMyProp (Value: integer);
begin
  MyProp := Value;
end;


... Which would translate in D to:

class MyClass
{
public:
   int myProp read getMyProp write setMyProp;

private:
   int getMyProp()
   {
      return myProp;
   }

   void setMyProp (int value)
   {
      myProp = value;
   }
}

read and write would be keywords here, but you
could also use get and set ofcourse, this is just
how Delphi does it.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail



June 16, 2002
You could use in and out keywords.

class MyClass
{
public:
   int myProp out getMyProp in setMyProp;

private:
   int getMyProp()
   {
      return myProp;
   }

   void setMyProp (int value)
   {
      myProp = value;
   }
}

Personally I'd rather have something a little more concise;  regular function syntax isn't necessary:

AND I'd rather properties not necessarily be restricted to class members!

int myProp
{
    out { return goComputeMyProp(); }
    in(x) { goNotifySomeoneThatMyPropChanged(x); }
}

Sean

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:aei3b8$2f48$1@digitaldaemon.com...
> "Jonas" <jonas.vermeulen@student.kuleuven.ac.be> wrote in message news:adcg8g$2j06$1@digitaldaemon.com...
>
> ... Which would translate in D to:
>
> class MyClass
> {
> public:
>    int myProp read getMyProp write setMyProp;
>
> private:
>    int getMyProp()
>    {
>       return myProp;
>    }
>
>    void setMyProp (int value)
>    {
>       myProp = value;
>    }
> }
>
> read and write would be keywords here, but you
> could also use get and set ofcourse, this is just
> how Delphi does it.



July 14, 2002
i like the () because it makes things look clearer.

i think the property (or some other) keyword should solve this problem better.

Sean L. Palmer wrote:
> I agree..  I always considered the () superfluous.  If I wanted the address
> of a function I'd use &foo.
> 
> I don't see why the property private variable and the property externally
> visible name should be the same.  Anywhere else it's a redeclaration and is
> illegal.
> 
> Sean
> 
> "Karl Bochert" <kbochert@ix.netcom.com> wrote in message
> news:1103_1023338484@bose...
> 
>>On Wed, 5 Jun 2002 17:26:31 -0700, "Walter" <walter@digitalmars.com>
> 
> wrote:
> 
>>>"Jonathan Andrew" <jon@ece.arizona.edu> wrote in message
>>>news:3CFE82EF.90305@ece.arizona.edu...
>>>
>>>>Of course this example is simple and could be replaced by simply
>>>>using a public variable. But the important part is the property
>>>>keyword. I don't know if that would make anything easier or not,
>>>>but I really hope you can include this kind of properties syntax
>>>>into D regardless of whether it uses a special keyword or not.
>>>>Just an idea...
>>>
>>>Unfortunately, I don't see how that will resolve the particular problem
>>
> with
> 
>>>the confusion between f.a and f.a().
>>>
>>
>>I doubt that this is news but:
>>
>>  UNIFORM ACCESS PRINCIPLE
>>All services offered by a module should be available through a
>>uniform notation, which does not betray whether they are implemented
>>through storage or through computation.
>>--- Bertrand Meyer
>>
>>The issue is not variables (f.a) versus functions (f.a())  but features
> 
> which do
> 
>>or do not take parameters.
>>
>>f.a and f.a() should be  the same thing, regardless of what 'a' is.
> 
> 
> 
> 


1 2 3
Next ›   Last »