Now that I have my major plea off my chest (throws clause), I have a couple of other small nits.

First of all, relating to exceptions, I don't think that the base class for exception handling should be called 'Error'.  I think that is too strong a term.  I really like Java's base class name: Throwable.  Hey, if you can throw it it's throwable, right? :)  That class is then subclassed to Error and Exception.  This dichotomy is very useful, as it makes a greater distinction between things that are easily recoverable, and things that might merit more drastic action (entire program bailing).

Second idea:  I'm thinking that the test() and invariant() functions in classes perhaps should be reduced to code blocks... e.g.

class Foo {
    int a;
    this() { a=1; }
    void Bar() { a = (a==1) ? 2 : 1; }
    invariant() { assert((a==1) || (a==2)); }
    test() { Bar(); Bar(); Bar(); }
}

becomes:

class Foo {
    int a;
    this() { a=1; }
    void Bar() { a = (a==1) ? 2 : 1; }
    invariant { assert((a==1) || (a==2)); }
    test { Bar(); Bar(); Bar(); }
}

The only difference is that invariant and test aren't functions anymore.   I only have one reason to suggest this, and that is:  If they are going to get compiled out, perhaps they shouldn't be normal functions. The compiler can treat them however it wants, but one shouldn't be able to call them, as the current spec implies you can.  Rather, I think they should resemble the 'in' and 'out' blocks more.

Third:  There doesn't appear to be an *easy* way to generate a reference doc for a class, something which is really useful.  Java has JavaDoc. C/C++ have headers.  Have you thought about something like that?  This could fit into the whole "compiler does HTML" category...

Last thing, and then I'll shut up, I promise.  Interfaces.  I'm not quite sure how they work, and the spec really isn't clear on this.  Is an interface simply a class that is not allowed to have any data members or body sections to its functions?

Well, that's it for me for now.  Walter, thank you very much for your work so far, I'm really impressed, and really looking forward to using your compiler the minute it comes out.  If there's any way I can help out, let me know.  (Mind you, I've never written class libraries... so I can't help there. :)

Cheers,

Eric

P.S.  Can you tell that my three posts were originally one that got too big?  I talk too much.

Eric Gerlach wrote in message <3B8836DB.7090407@canada.com>...
>First of all, relating to exceptions, I don't think that the base class for exception handling should be called 'Error'.  I think that is too strong a term.  I really like Java's base class name: Throwable.  Hey, if you can throw it it's throwable, right? :)

How about "Exception"? After all, that's what it is.

>Second idea:  I'm thinking that the test() and invariant() functions in
>classes perhaps should be reduced to code blocks... e.g.


I hadn't noticed that the () are redundant for them, but you're right, they
are.

>The compiler can treat them however it wants, but one shouldn't be able to call them, as the current spec implies you can.  Rather, I think they should resemble the 'in' and 'out' blocks more.


Yes, I think they should be callable even when compiled out. The reason is so you can mix&match mutually dependent modules that have them compiled in and out.

>Third:  There doesn't appear to be an *easy* way to generate a reference doc for a class, something which is really useful.  Java has JavaDoc. C/C++ have headers.  Have you thought about something like that?  This could fit into the whole "compiler does HTML" category...


The HTML thing looks at the problem from the other way - generating the code from the documentation!


>Last thing, and then I'll shut up, I promise.  Interfaces.  I'm not quite sure how they work, and the spec really isn't clear on this.  Is an interface simply a class that is not allowed to have any data members or body sections to its functions?


Yes. It's an extra vtable and a promise that each function in the vtable will be filled in.

> Eric Gerlach wrote in message <3B8836DB.7090407@canada.com>...
> 
>>First of all, relating to exceptions, I don't think that the base class
>>for exception handling should be called 'Error'.  I think that is too
>>strong a term.  I really like Java's base class name: Throwable.  Hey,
>>if you can throw it it's throwable, right?  :)
>
> How about "Exception"? After all, that's what it is.

Well... yes, that works. :)  I was commenting that the Error/Exception dichotomy can be useful.  However, there is definite merit in the KISS of leaving it out.

>>The compiler can treat them however it wants, but one shouldn't be able
>>to call them, as the current spec implies you can.  Rather, I think they
>>should resemble the 'in' and 'out' blocks more.
>
> Yes, I think they should be callable even when compiled out. The reason is
> so you can mix&match mutually dependent modules that have them compiled in
> and out.

Oops, my bad, I wasn't very clear on my point.  What I meant was that it appeared from the current syntax that one could call foo.invariant() or foo.test() manually if one wanted to, and if they compiled out that might not be cool (though I guess they could just be no-ops)  But if the () are redundant, then that kinda solves the problem now doesn't it!

If you're familiar with Java's Interfaces, that's what Walter is going for with D interfaces.  You can only "extend" one super-class, but can "implement" any number of interfaces you want.

Your comment "is an interface simply a class that is not allowed to have any data members or body sections in it's functions" is completely correct.  An interface is nothing but a collection of abstract function specs.  But, to nit-pick, in Java, an interface can't have instance member data, but it CAN have static member data.  Static or not, methods must still be empty.

I extend this question to Walter - Will static member variables in interfaces be allowed?  To dig deeper, in Java they're allowed whether or not they're final - ie, they can be changed.   Will D allow static interface data at all and, if so, just constants or will variables be allowed as well?

Yes, it's a small point, but I do use static data in Java interfaces all the time and I just want to make sure they'll still be there.  :)

-Brady


> Last thing, and then I'll shut up, I promise.  Interfaces.  I'm not quite sure how they work, and the spec really isn't clear on this.  Is an interface simply a class that is not allowed to have any data members or body sections to its functions?

Bradeeoh wrote in message <9m9vu7$i39$1@digitaldaemon.com>...
>I extend this question to Walter - Will static member variables in interfaces be allowed?  To dig deeper, in Java they're allowed whether or not they're final - ie, they can be changed.   Will D allow static
interface
>data at all and, if so, just constants or will variables be allowed as
well?


I didn't know Java allowed static members. I think D will allow all but per-instance data.

Walter wrote:
> 
> Eric Gerlach wrote in message <3B8836DB.7090407@canada.com>...
> >First of all, relating to exceptions, I don't think that the base class for exception handling should be called 'Error'.  I think that is too strong a term.  I really like Java's base class name: Throwable.  Hey, if you can throw it it's throwable, right? :)
> 
> How about "Exception"? After all, that's what it is.

Is there a compiler reason why C++'s throw-of-any-type won't work well?

-R

Russell Bornschlegel wrote in message <3B89ED69.166E5344@estarcion.com>...
>Is there a compiler reason why C++'s throw-of-any-type won't work well?


It simplifies the internal workings of the compiler and the implementation of the runtime library support if only class objects can be thrown.

I've also never seen a credible use for (or even an argument for) throwing int's or unsigned char **'s, so I doubt that will be missed.

Walter wrote:
> It simplifies the internal workings of the compiler and the implementation of the runtime library support if only class objects can be thrown.

OK, that's a good enough argument for me.

> I've also never seen a credible use for (or even an argument for) throwing
> int's

As a transition for people used to errno-style error handling, maybe?

> or unsigned char **'s, so I doubt that will be missed.

char* (or, in D, char[]) as the everything-else exception (i.e.
caller/catcher can't do anything except report and die) is
defensible, but it's easy enough to wrap this or int into an
exception class.

-RB

Walter wrote:
> Russell Bornschlegel wrote in message <3B89ED69.166E5344@estarcion.com>...
> 
>>Is there a compiler reason why C++'s throw-of-any-type won't work
>>well?
>>
> 
> 
> It simplifies the internal workings of the compiler and the implementation
> of the runtime library support if only class objects can be thrown.
> 
> I've also never seen a credible use for (or even an argument for) throwing
> int's or unsigned char **'s, so I doubt that will be missed.
> 
> 
> 

Perhaps.  But I generally prefer throwing strings.  I like to throw things that say something like:
"Class Rhinocerous :: Gore :: error 23 :: No kind of horn found"

The reason for throwing an int,  well, only to save time parsing the message.  So what I would really like to throw is:
17, 23, "Class Rhinocerous :: Gore :: error 23 :: No kind of horn found"

where 17 is some internally meaningful code that identifies class Rhinocerous and method gore.  I suppose that:
"Rhinocerous", "Gore", 23, "Class Rhinocerous :: Gore :: error 23 :: No kind of horn found"

might be even better.  So I'm getting toward a specialized class, alright.  But it's not exactly the kind I usually run into as being throwable in those languages that put restrictions on.

And usually I just want to throw a string.

Charles Hixson wrote:

> Perhaps.  But I generally prefer throwing strings.  I like to throw
> things that say something like:
> "Class Rhinocerous :: Gore :: error 23 :: No kind of horn found"
>
> The reason for throwing an int,  well, only to save time parsing the
> message.  So what I would really like to throw is:
> 17, 23, "Class Rhinocerous :: Gore :: error 23 :: No kind of horn found"
>
> where 17 is some internally meaningful code that identifies class
> Rhinocerous and method gore.  I suppose that:
> "Rhinocerous", "Gore", 23, "Class Rhinocerous :: Gore :: error 23 :: No
> kind of horn found"
>
> might be even better.  So I'm getting toward a specialized class, alright.  But it's not exactly the kind I usually run into as being throwable in those languages that put restrictions on.
>
> And usually I just want to throw a string.

Removing char* throws just means that we implement a char* constructor in the Error() class.  Your code changes from

throw "Class Rhinocerous :: Gore :: error 23 :: No kind of horn found";
    to
throw Error("Class Rhinocerous :: Gore :: error 23 :: No kind of horn found");

which isn't very bad, IMHO, and it simplifies the exception handling some.

OR MAYBE...if you pass a non-class type as an exception, the compiler automatically turns it into a call of a constructor on the Error() class?  It would be a syntax error if you try to throw a type that has no constructor.