www.digitalmars.com         C & C++   DMDScript  

D - Some more small stuff

reply Eric Gerlach <egerlach canada.com> writes:
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.
Aug 25 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
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.
Aug 25 2001
next sibling parent Eric Gerlach <egerlach canada.com> writes:
 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!
Aug 25 2001
prev sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
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
Aug 26 2001
parent reply "Walter" <walter digitalmars.com> writes:
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.
Aug 27 2001
next sibling parent Russell Bornschlegel <kaleja estarcion.com> writes:
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
Aug 27 2001
prev sibling next sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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.
Aug 27 2001
parent reply Russ Lewis <russ deming-os.org> writes:
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.
Aug 27 2001
parent Charles Hixson <charleshixsn earthlink.net> writes:
Russ Lewis wrote:

 Charles Hixson wrote:
 ...> 
 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.
 
 


That does everything that I wanted.  I was misunderstanding when you 
said "remove throwing char**".  I certainly don't see anything wrong 
with putting a wrapper around it.  (And it could be quite useful.)
Aug 27 2001
prev sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
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.


  I just thought of something.  Could exception possibly be an interface
instead of a class?  It might be convienient of declare a useful type as
something that can also be thrown.  Otherwise you would have to define
an exception class that has the type you'd really like to throw as a
member.  That's doable, but the interface might be easier.  If we
eventually get a way to declare generic types, the wrapper class would
be less of a problem too.  Just thought I'd ask.

Dan
Aug 27 2001
parent reply Eric Gerlach <egerlach canada.com> writes:
 I just thought of something.  Could exception possibly be an interface
 instead of a class?  It might be convienient of declare a useful type as
 something that can also be thrown.  Otherwise you would have to define
 an exception class that has the type you'd really like to throw as a
 member.  That's doable, but the interface might be easier.  If we
 eventually get a way to declare generic types, the wrapper class would
 be less of a problem too.  Just thought I'd ask.


I'm not sure I understand the point here, but I think it's mostly moot. 
  I guess what I'm not sure about is what you mean by a "useful type" to 
be thrown as an exception.  If all exceptions have to implement an 
interface, then they have to be classes.  I can't see how even with 
exception as an interface you plan to throw another type other than an 
object reference.

If I'm totally missing the point, I'm terribly sorry.  I'm just not sure 
exactly what you're trying to accomplish...

Eric
Aug 27 2001
parent Dan Hursh <hursh infonet.isl.net> writes:
Eric Gerlach wrote:

 

 I just thought of something.  Could exception possibly be an interface
 instead of a class?  It might be convienient of declare a useful type as
 something that can also be thrown.  Otherwise you would have to define
 an exception class that has the type you'd really like to throw as a
 member.  That's doable, but the interface might be easier.  If we
 eventually get a way to declare generic types, the wrapper class would
 be less of a problem too.  Just thought I'd ask.


 
 I'm not sure I understand the point here, but I think it's mostly moot.
   I guess what I'm not sure about is what you mean by a "useful type" to
 be thrown as an exception.  If all exceptions have to implement an
 interface, then they have to be classes.  I can't see how even with
 exception as an interface you plan to throw another type other than an
 object reference.
 
 If I'm totally missing the point, I'm terribly sorry.  I'm just not sure
 exactly what you're trying to accomplish...


	That's because I wasn't clear.  :-)  I'm not trying to avoid throwing
an object, I'm try to keep from inventing a new type to throw.  I can
create a class that, among other things, implements Exception.  Then
during processing, if I find that I have such an object in a bad state,
I throw it at some one to have it fixed.
	If Exception is a class, then my exception is only a class.  That's
it.  I have to create a new class for each type of exception, solely for
the purpose of throw.  I guess I have the fact that exception have to be
declared as a full class when in most cases I would be doing:

	class TooManyMoves : Exception {} // You SUCK!
	class InvalidMove  : Exception {} // no no no
	class InvalidSetup : Exception {}  // board can be setup this way

when I would almost rather say:

	Exception TooManyMoves,	 // You SUCK!
	          InvalidMove,   // no no no
	   	  InvalidSetup;  // board can be setup this way

Or worse:
	class MyException : Exception{
	    public:
		mytype problem_data;
		MyException(mytype meaningful_stuff):
			problem_data(meaningful_stuff){}
	}

when it should be enough to say:	

	Exception<mytype> MyException;

I know this syntax is garbage, but I think the class declaration syntax
is always overkill for what people do with exceptions.  That why a lot
of people just use strings.  In the end you are declaring an exception
type because you want a unique symbol that might wrap a message and/or
piece of data.
	I don't know if this an annoyance to anyone else or not, but it was the
primary reason why I was slow to use exceptions instead of return codes
in my classes in C++ and Java.

Dan
Aug 27 2001
prev sibling parent reply "Bradeeoh" <bradeeoh crosswinds.net> writes:
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?
Aug 25 2001
parent "Walter" <walter digitalmars.com> writes:
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.
Aug 26 2001