"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 enough. My experience with properties is largely from Delphi, but C# 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

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
> enough. My experience with properties is largely from Delphi, but C#
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
>
>
>
>
>
>
>

Further D comments:

C#, unlike Delphi,  doesn't have named gettors and settor methods in a 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.

In the C# code above, this explains why { return getSomeVal(); } is in some 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