D - final time
- Jonas (5/5) Jun 01 2002 Hi, I'm very upset with the D language, but the current compiler still
- Jonas (4/9) Jun 01 2002 Of course I mean I'm really enthousiastic about the language. I'm sorry ...
- Walter (6/17) Jun 01 2002 for
- Pavel Minayev (22/24) Jun 02 2002 Please, no!
-
Walter
(4/28)
Jun 02 2002
Ok, ok, I'm just going to have to work harder at this
. - Karl Bochert (12/36) Jun 02 2002 I hadn't seen that syntax before -- much better!
- Patrick Down (4/15) Jun 02 2002 How would you access width inside the class wihout calling
- Karl Bochert (8/26) Jun 02 2002 1) the absence of a get clause causes the compiler to treat
- Pavel Minayev (7/10) Jun 02 2002 What about read-only (and write-only) properties then???
- Karl Bochert (32/46) Jun 02 2002 Another case where one might want to use a shadow
- Patrick Down (8/31) Jun 02 2002 Yes but setting of the width value will cause a repaint. This is
- Karl Bochert (15/40) Jun 02 2002 I hadn't thought of that use of set and get.
- Sean L. Palmer (76/117) Jun 03 2002 Why not treat it like a spontaneously generated anonymous struct
- Walter (17/36) Jun 03 2002 I'm not too thrilled with that approach. It just seems like a lot of syn...
- Pavel Minayev (6/19) Jun 03 2002 As long as it works, I don't really care much about the syntax.
-
Walter
(4/8)
Jun 05 2002
I do
. - Jonathan Andrew (28/44) Jun 05 2002 Walter, earlier I got the impression that you were having some
- Walter (4/10) Jun 05 2002 Unfortunately, I don't see how that will resolve the particular problem ...
- Jonathan Andrew (5/10) Jun 05 2002 Hmm, that stinks. Do you have any other alternatives or solutions that
- Patrick Down (15/29) Jun 05 2002 Couldn't using the property attribute disallow
- Karl Bochert (10/23) Jun 05 2002 I doubt that this is news but:
- Sean L. Palmer (11/34) Jun 05 2002 I agree.. I always considered the () superfluous. If I wanted the addr...
- Marius S. (4/56) Jul 14 2002 i like the () because it makes things look clearer.
- Patrick Down (28/54) Jun 05 2002 I like Pavel's syntax best but how about.
- Jonas (4/7) Jun 02 2002 Though they are not necessary, I would find it a big loss for D it won'...
- OddesE (46/55) Jun 16 2002 to
- Sean L. Palmer (26/46) Jun 16 2002 You could use in and out keywords.
Hi, I'm very upset with the D language, but the current compiler still misses a few important things (listed on the website, like property gettor/settor, packages, templates,...). Do you have an idea when a more complete version will be available? This would make it much more valuable.
Jun 01 2002
"Jonas" <jonas.vermeulen student.kuleuven.ac.be> wrote in message news:ada4qv$3029$1 digitaldaemon.com...Hi, I'm very upset with the D language, but the current compiler still misses a few important things (listed on the website, like property gettor/settor, packages, templates,...). Do you have an idea when a more complete version will be available? This would make it much more valuable.Of course I mean I'm really enthousiastic about the language. I'm sorry for the wrong word choice, strange thought.
Jun 01 2002
"Jonas" <jonas.vermeulen student.kuleuven.ac.be> wrote in message news:adaj51$i99$1 digitaldaemon.com..."Jonas" <jonas.vermeulen student.kuleuven.ac.be> wrote in message news:ada4qv$3029$1 digitaldaemon.com...forHi, I'm very upset with the D language, but the current compiler still misses a few important things (listed on the website, like property gettor/settor, packages, templates,...). Do you have an idea when a more complete version will be available? This would make it much more valuable.Of course I mean I'm really enthousiastic about the language. I'm sorrythe wrong word choice, strange thought.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.
Jun 01 2002
"Walter" <walter digitalmars.com> wrote in message news:adb2h9$11qt$1 digitaldaemon.com...version 2 of the language. The property gettors/settors are turning out to be a problem, they may just get dumped.Please, no! If it seems hard to implement them in the way documented in the reference, then class Button { private int m_width; public int width { get { return m_width; } set { m_width = value; repaint(); } } }
Jun 02 2002
"Walter" <walter digitalmars.com> Ok, ok, I'm just going to have to work harder at this <g>. "Pavel Minayev" <evilone omen.ru> wrote in message news:adcg51$2imn$1 digitaldaemon.com..."Walter" <walter digitalmars.com> wrote in message news:adb2h9$11qt$1 digitaldaemon.com...toversion 2 of the language. The property gettors/settors are turning outbe a problem, they may just get dumped.Please, no! If it seems hard to implement them in the way documented in the reference, then class Button { private int m_width; public int width { get { return m_width; } set { m_width = value; repaint(); } } }
Jun 02 2002
On Sun, 2 Jun 2002 11:11:59 +0400, "Pavel Minayev" <evilone omen.ru> wrote:
Please, no!
If it seems hard to implement them in the way documented in the reference,
then
class Button
{
private int m_width;
public int width
{
get
{
return m_width;
}
set
{
m_width = value;
repaint();
}
}
}
I hadn't seen that syntax before -- much better!
Even better would be to further blur the distinction between data
and functions by not requiring the dummy m_width:
public int width {
// ok to omit get ??
set {
self = value; // two keywords !
repaint ();
}
}
...
Jun 02 2002
Karl Bochert <kbochert ix.netcom.com> wrote in
news:1103_1023031499 bose:
Even better would be to further blur the distinction between data
and functions by not requiring the dummy m_width:
public int width {
// ok to omit get ??
set {
self = value; // two keywords !
repaint ();
}
}
...
How would you access width inside the class wihout calling
the function?
Jun 02 2002
On Sun, 2 Jun 2002 16:32:52 +0000 (UTC), Patrick Down <pat codemoon.com> wrote:Karl Bochert <kbochert ix.netcom.com> wrote in news:1103_1023031499 bose:1) the absence of a get clause causes the compiler to treat accesses to width just like any other variable, whether inside the class or not. Likewise for set of course. 2) In a more general sense, the compiler may in-line both the get and set functions if they were sufficiently short. The D documentation says "The compiler makes the decision whether to inline a function or not...".Even better would be to further blur the distinction between data and functions by not requiring the dummy m_width: public int width { // ok to omit get ?? set { self = value; // two keywords ! repaint (); } } ...How would you access width inside the class wihout calling the function?
Jun 02 2002
"Karl Bochert" <kbochert ix.netcom.com> wrote in message
news:1103_1023039833 bose...
1) the absence of a get clause causes the compiler to treat
accesses to width just like any other variable, whether inside
the class or not. Likewise for set of course.
What about read-only (and write-only) properties then???
Besides, sometimes you just don't need a temporary. For example,
the Width property of Button will most likely call MoveWindow
to set, and GetWindowRect to get the actual position. Additional
variable would be just a waste of space...
Jun 02 2002
On Sun, 2 Jun 2002 23:37:40 +0400, "Pavel Minayev" <evilone omen.ru> wrote:"Karl Bochert" <kbochert ix.netcom.com> wrote in message news:1103_1023039833 bose...Another case where one might want to use a shadow variable. But it should not be mandatory.1) the absence of a get clause causes the compiler to treat accesses to width just like any other variable, whether inside the class or not. Likewise for set of course.What about read-only (and write-only) properties then???Besides, sometimes you just don't need a temporary. For example, the Width property of Button will most likely call MoveWindow to set, and GetWindowRect to get the actual position. Additional variable would be just a waste of space...1) It ought to be easy for a compiler to optimize away the storage when a variable has both set and get clauses, neither of which access 'self'. i.e: int width { get { return Get_width(); } set { Set_width (value); } } The line 'width = 5;' would just be coded as a call to the set function, unless the compiler were smart enough to inline short routines. Likewise with 'w = width ;' . 2) Besides, sometimes you just don't need a shadow variable. int width { set { self = max ( value, MAXWIDTH) ; } } Do you suppose that access control could be imposed on the variable and the get and set clauses separately ?? private int width { public get { return self ; } } Or even overloaded ???? private int width { public set { self = value; Repaint () } private set { self = value; } }
Jun 02 2002
Karl Bochert <kbochert ix.netcom.com> wrote in news:1103_1023039833 bose:On Sun, 2 Jun 2002 16:32:52 +0000 (UTC), Patrick Down <pat codemoon.com> wrote:Yes but setting of the width value will cause a repaint. This is appropriate when accessing width from outside the class. However from inside the class a programmer may wish to short cut the process. Effeciency may be one reason. You might want to be able adjust the values of width and height before doing a repaint. If setting the value of width always calls the set function this is not possible.Karl Bochert <kbochert ix.netcom.com> wrote in news:1103_1023031499 bose:1) the absence of a get clause causes the compiler to treat accesses to width just like any other variable, whether inside the class or not. Likewise for set of course.Even better would be to further blur the distinction between data and functions by not requiring the dummy m_width: public int width { // ok to omit get ?? set { self = value; // two keywords ! repaint (); } } ...How would you access width inside the class wihout calling the function?
Jun 02 2002
On Sun, 2 Jun 2002 19:36:10 +0000 (UTC), Patrick Down <pat codemoon.com> wrote:I hadn't thought of that use of set and get. My argument is for the set and get clauses being optional, and doesn't prevent using a 'shadow' variable to allow clients inside and outside of the class to have different priviledges. I would think a more common use would be something like: int width { set { self = max(value, MAXWIDTH) } } which is certainly more straight-forward than : int shadow_width; int width { set { shadow_width = max ( value, MAXWIDTH) } get ( return shadow_width; } }Yes but setting of the width value will cause a repaint. This is appropriate when accessing width from outside the class. However from inside the class a programmer may wish to short cut the process. Effeciency may be one reason. You might want to be able adjust the values of width and height before doing a repaint. If setting the value of width always calls the set function this is not possible.1) the absence of a get clause causes the compiler to treat accesses to width just like any other variable, whether inside the class or not. Likewise for set of course.Even better would be to further blur the distinction between data and functions by not requiring the dummy m_width: public int width { // ok to omit get ?? set { self = value; // two keywords ! repaint (); } } ...How would you access width inside the class wihout calling the function?
Jun 02 2002
Why not treat it like a spontaneously generated anonymous struct
class foo
{
int width { }
}
that declares a struct width which consists of one member, an int, which
internally to the struct is known as width. Outsider stores to width map
straight to the contained int, and outsider reads do so as well.
Now if you want to get fancy you can overload operator = (aka set)
class foo
{
int width
{
void set(int v) { WidthChangedOldToNew(width,v); } // the store to
the shadow variable is implied?
// If nothing
in here uses it, it could be optimized away.
// the get property is automatically generated and by default it
returns the shadow variable
}
}
The compiler automatically knows the rules for lvalues. The only difference
between this and a normal variable in the compiler is that these can't
automatically be promoted to a rvalue and reads and writes go through
(probably inlined) functions. In fact I'd bar side effects inside get
functions since they cause outside code to not be able to be properly
optimized (it can't be sure the value didn't change during the first call so
it has to call it again). You can hope the compiler can tell the variable
doesn't change, but sometimes it can't. But this brings up the issue of
const being a type modifier rather than a storage class. If it's a type
modifier, you can use it to ensure that nobody tries to modify the variable
(the compiler could enforce this by making copies of params it passes
elsewhere). If it's a storage class, that prevents direct writes but
doesn't prevent indirect writes (i.e. thru a pointer). Then the user gets
no guarantees and the compiler has no way to enforce anything. But it can
still guarantee correctness if it always makes a copy when sending a const
variable by reference. But what this really boils down to is that the get
method should return a *value*, something for which a copy is as good as the
original which indicates that copying doesn't change state. Class objects
aren't like this and usually don't get copied, which is why I think of
properties as more of an anonymous struct than an anonymous class. This is
so that the calling code can take several references to the same property
and optimize them together into one call to the property function followed
by several uses or copies of the resulting value. Without this guarantee,
properties will be fairly expensive to call at runtime unless the properties
are trivial or the caller is smart and caches the result. But we don't want
the callers to have to know whether it's an optimizable variable reference
or a call to a get property function, so in order to generate the best code
possible we should give the compiler the freedom to assume the value doesn't
change without some intervening call to set. That means the get function
should have no side effects. Synchronization would break that. Maybe the
compiler just has to figure out whether any side effects are present and
notify the property callers whether the result is cacheable/read combinable
or not so that the point of call can generate the corresponding code. If
everything gets inlined properly this should be possible.
Other kinds of structs have need of overloading assignment and conversion to
rvalue also. Not to mention other operators.
class foo
{
int width
{
void set(int v) { WidthChangedOldToNew(width,v); }
private int get(); // make width a write-only property (this is like
C++'s operator int)
}
}
Does anyone else see the connection between operator = and set, and
operator typeconvert and get?
And anonymous structs could be constructed lots of places, like maybe while
passing a parameter:
DrawWindowBorder({int left,right,top,bottom;}={0,25,0,15},colors.lightgrey);
Or would that get too confusing...
Sean
"Karl Bochert" <kbochert ix.netcom.com> wrote in message
news:1104_1023078664 bose...
On Sun, 2 Jun 2002 19:36:10 +0000 (UTC), Patrick Down <pat codemoon.com>
wrote:
Even better would be to further blur the distinction between data
and functions by not requiring the dummy m_width:
public int width {
// ok to omit get ??
set {
self = value; // two keywords !
repaint ();
}
}
...
How would you access width inside the class wihout calling
the function?
1) the absence of a get clause causes the compiler to treat
accesses to width just like any other variable, whether inside
the class or not. Likewise for set of course.
Yes but setting of the width value will cause a repaint. This is
appropriate when accessing width from outside the class. However
from inside the class a programmer may wish to short cut the process.
Effeciency may be one reason. You might want to be able adjust the
values of width and height before doing a repaint. If setting the
value of width always calls the set function this is not possible.
I hadn't thought of that use of set and get.
My argument is for the set and get clauses being optional, and
doesn't prevent using a 'shadow' variable to allow clients inside
and outside of the class to have different priviledges.
I would think a more common use would be something like:
int width {
set { self = max(value, MAXWIDTH) }
}
which is certainly more straight-forward than :
int shadow_width;
int width {
set { shadow_width = max ( value, MAXWIDTH) }
get ( return shadow_width; }
}
Jun 03 2002
"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
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>.
The D approach leaves one with:
class Foo
{
int a();
}
Foo f;
return f.a;
In other words, does it make sense to consider
a
and
a()
as generally equivalent, if a is a function? Note that in C, a and &a are
equivalent if a is a function.
Jun 03 2002
"Walter" <walter digitalmars.com> wrote in message
news:adgp6f$2e9o$1 digitaldaemon.com...
The D approach leaves one with:
class Foo
{
int a();
}
Foo f;
return f.a;
In other words, does it make sense to consider
a
and
a()
as generally equivalent, if a is a function? Note that in C, a and &a are
equivalent if a is a function.
As long as it works, I don't really care much about the syntax.
Yours is less "consistent", but it's shorter, and I don't know
what I like more.
By the way, I hope settors are also there?
Jun 03 2002
"Pavel Minayev" <evilone omen.ru> wrote in message news:adhnr4$bnq$1 digitaldaemon.com...As long as it works, I don't really care much about the syntax.I do <g>.Yours is less "consistent", but it's shorter, and I don't know what I like more. By the way, I hope settors are also there?It's really the same issue.
Jun 05 2002
Walter wrote:"Pavel Minayev" <evilone omen.ru> wrote in message news:adhnr4$bnq$1 digitaldaemon.com...Walter, earlier I got the impression that you were having some difficulty implementing the properties with the syntax you had decided on. I really liked the way you had come up with, and I am sorry to see that it might not make it. Would it be easier to make it work if the variables were identified with a "property" keyword? I think it would make the code more readable also. i.e. class foo { property int someprop; void prop(int s) //setter { someprop = s; } int prop(void) //getter { return someprop; } } 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... -JonAs long as it works, I don't really care much about the syntax.I do <g>.Yours is less "consistent", but it's shorter, and I don't know what I like more. By the way, I hope settors are also there?It's really the same issue.
Jun 05 2002
"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().
Jun 05 2002
Walter wrote:Hmm, that stinks. Do you have any other alternatives or solutions that you've been considering? I'm sure there is some kind of nice way to pull this off. -JonUnfortunately, I don't see how that will resolve the particular problem with the confusion between f.a and f.a().
Jun 05 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...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 pointerOf 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().
Jun 05 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...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.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().
Jun 05 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:with"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 problemwhich dothe 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 featuresor do not take parameters. f.a and f.a() should be the same thing, regardless of what 'a' is.
Jun 05 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:with"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 problemwhich dothe 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 featuresor do not take parameters. f.a and f.a() should be the same thing, regardless of what 'a' is.
Jul 14 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...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; } }If it seems hard to implement them in the way documented in the reference, then 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>.
Jun 05 2002
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.
Jun 02 2002
"Jonas" <jonas.vermeulen student.kuleuven.ac.be> wrote in message news:adcg8g$2j06$1 digitaldaemon.com...toThe packages are implemented. The templates are not defined and are for version 2 of the language. The property gettors/settors are turning outbebe a problem, they may just get dumped.Though they are not necessary, I would find it a big loss for D it won'timplemented. 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
Jun 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.
Jun 16 2002