www.digitalmars.com         C & C++   DMDScript  

D - Comments from a passer-by

reply "Anthony Steele" <asteele nospam.iafrica.com> writes:
"D is for lots of things" - Sandman

Hi

Excuse me for taking an interest in your language. I'm just a programmer who
read about it on slashdot & thought it was cool. Now if I thought it sucked,
I wouldn't bother to critique it at all.

Herewith my comments:

Booleans:
----------
If you do not have a Boolean type (which I think would be a sad omission),
please document what precisely is returned by expressions like (a > b) and
update the docs for the if statement that refer to the Boolean type.

If we are suppoed to use bit instead for true/false flags, then how about
making the words 'true' and 'false' built in synonyms for 1 and 0, though
IMHO this is inferior to a boolean type that must be forcibly converted to a
number. IMHO it would be a good idea if code like

Int a = 10;
While (a) do { . }

Was not legal. Mixing integers and Booleans is error-prone.


Properties.
-----------
Your attention to object properties is commendable, but IMHO does not go far

a very similar route.

Properties in Delphi read like this:

Property SomeValue: integer read GetSomeValue  write SetSomeValue;

This has the advantages:

It is explicit. You are not, as with Java beans, left to assume from the
coincidence of names that a property is expected to appear automagically.
The property is there because you stated that it is there.

It is all together. It would seem with the draft D spec that the gettor and
settor could be at opposite ends of the class and still together form a
property. This is not readable. With this style, the property is one
declaration.

It is flexible. There are no restrictions on the names of the gettor and
settor methods. Given methods foo and bar of the right type, you could have

  Property SomeValue: integer read Foo  write Bar;

It is flexible. You can have read-only and write-only properties simply by
omitting clauses.

e.g. Property SomeReadOnlyValue: integer read Foo;

  Property SomeSecretValue: integer write Bar;

It allows array properties.

E.g   Property Stuff[const piIndex: integer] : integer read GetStuff write
SetStuff;

Now you can write MyStuff.Stuff[3] := MyStuff.Stuff[4]; and if you declare
it as such, your array index can be any type, not just an int. It can be a
float or a string, and it is up to the gettor and settor to map this to the
class's internals.

Even better, an array property can be made default. (an object can have at
most 1 default array property)
  Property Stuff[const piIndex: integer] : integer read GetStuff write
SetStuff; default;

So you can write MyStuff [3] := MyStuff [4];

You wouldn't want to end up with inferior constructs to a language that had
all these features in 1995 already, now would you?


Constructors:
-------------

The naming of constructors is to me opaque and inconsistent:
Constructor: this
Destructor: ~this
Class constructor: _staticCtor
Class destructor: _staticDdor

How about the call-a-spade-a-spade approach:

Constructor: constructor
Destructor: destructor
Class constructor: classconstructor
Class destructor: classdestructor

as in

class B : A
 { int j;
   constructor()


      ...blah...
      super(3); // call base constructor A(3)

 }
}


Or if you prefer brevity over readability (on the basis that the most
frequently used words in a language are usually the shortest):

Constructor: ctor
Destructor: dtor
Class constructor: classctor
Class destructor: classdtor

Templates:
---------
These fall into the category of "not essential, would be nice, but can be
real ugly". Leave them for a 1.1 realese if they are problematic. I'm not in
favour of templates anwhere, anytime. All I really want is a paramterised
class template, ie list of *sometype*.

Cheers and Good D'ing
Anthony
Aug 21 2001
next sibling parent "Walter" <walter digitalmars.com> writes:
Thanks. Some good ideas. -Walter

"Anthony Steele" <asteele nospam.iafrica.com> wrote in message
news:9ludh8$2kb8$1 digitaldaemon.com...

 "D is for lots of things" - Sandman

 Hi

 Excuse me for taking an interest in your language. I'm just a programmer


who

 read about it on slashdot & thought it was cool. Now if I thought it


sucked,

 I wouldn't bother to critique it at all.

 Herewith my comments:

 Booleans:
 ----------
 If you do not have a Boolean type (which I think would be a sad omission),
 please document what precisely is returned by expressions like (a > b) and
 update the docs for the if statement that refer to the Boolean type.

 If we are suppoed to use bit instead for true/false flags, then how about
 making the words 'true' and 'false' built in synonyms for 1 and 0, though
 IMHO this is inferior to a boolean type that must be forcibly converted to


a

 number. IMHO it would be a good idea if code like

 Int a = 10;
 While (a) do { . }

 Was not legal. Mixing integers and Booleans is error-prone.


 Properties.
 -----------
 Your attention to object properties is commendable, but IMHO does not go


far




follows

 a very similar route.

 Properties in Delphi read like this:

 Property SomeValue: integer read GetSomeValue  write SetSomeValue;

 This has the advantages:

 It is explicit. You are not, as with Java beans, left to assume from the
 coincidence of names that a property is expected to appear automagically.
 The property is there because you stated that it is there.

 It is all together. It would seem with the draft D spec that the gettor


and

 settor could be at opposite ends of the class and still together form a
 property. This is not readable. With this style, the property is one
 declaration.

 It is flexible. There are no restrictions on the names of the gettor and
 settor methods. Given methods foo and bar of the right type, you could


have

   Property SomeValue: integer read Foo  write Bar;

 It is flexible. You can have read-only and write-only properties simply by
 omitting clauses.

 e.g. Property SomeReadOnlyValue: integer read Foo;

   Property SomeSecretValue: integer write Bar;

 It allows array properties.

 E.g   Property Stuff[const piIndex: integer] : integer read GetStuff write
 SetStuff;

 Now you can write MyStuff.Stuff[3] := MyStuff.Stuff[4]; and if you declare
 it as such, your array index can be any type, not just an int. It can be a
 float or a string, and it is up to the gettor and settor to map this to


the

 class's internals.

 Even better, an array property can be made default. (an object can have at
 most 1 default array property)
   Property Stuff[const piIndex: integer] : integer read GetStuff write
 SetStuff; default;

 So you can write MyStuff [3] := MyStuff [4];

 You wouldn't want to end up with inferior constructs to a language that


had

 all these features in 1995 already, now would you?


 Constructors:
 -------------

 The naming of constructors is to me opaque and inconsistent:
 Constructor: this
 Destructor: ~this
 Class constructor: _staticCtor
 Class destructor: _staticDdor

 How about the call-a-spade-a-spade approach:

 Constructor: constructor
 Destructor: destructor
 Class constructor: classconstructor
 Class destructor: classdestructor

 as in

 class B : A
  { int j;
    constructor()


       ...blah...
       super(3); // call base constructor A(3)

  }
 }


 Or if you prefer brevity over readability (on the basis that the most
 frequently used words in a language are usually the shortest):

 Constructor: ctor
 Destructor: dtor
 Class constructor: classctor
 Class destructor: classdtor

 Templates:
 ---------
 These fall into the category of "not essential, would be nice, but can be
 real ugly". Leave them for a 1.1 realese if they are problematic. I'm not


in

 favour of templates anwhere, anytime. All I really want is a paramterised
 class template, ie list of *sometype*.

 Cheers and Good D'ing
 Anthony
Aug 21 2001
prev sibling parent "Anthony Steele" <asteele nospam.iafrica.com> writes:
Further D comments:


property def, it has java-style {} blocks in the propery def, for e.g.

public class PropertyHolder
{
    private int someProperty = 0;

    public int SomeProperty
    {
        get
       {
            return someProperty;
        }
        set
       {
            someProperty = value;
        }
    }
}


the block  could be just a ref of a var as shown above, or could be a
function call e.g. { return getSomeVal(); } or a whole whack of code,ie an
anonymous method. I have yet to decide if this last kind, not allowed in
delphi, is an improvement.

It is quite common in Delphi for the property to be public, and the gettors
and settors to be private - or more usefully, protected and virtual - this
means that a  base class can define what properties are exposed, and a child
class can decide/override how to implement them.


cases a better gettor block than the inline-whack-of-code approach: it can
be a virtual method.


 "D is for lots of things" - Sandman
Aug 30 2001