Digital Mars - D

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

But all the "is" operator would do is check the cast for a null return.  It
seems redundant.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9tmb6p$2snv$1 digitaldaemon.com...
 The specification says that all casts of objects are
 done with run-time checking - and that's good - and
 if the type doesn't match, null is returned! I don't
 think it's a good idea, since you could make a cast
 in one place of the program, and any error would get
 unnoticed, and then try to use the null-pointer in
 other place somewhere hundred lines after... could
 be VERY hard to find the actual reason of crash. Maybe
 it's better to throw an exception on bad cast - like
 it's done in C++ (and in Delphi by the way).

 On other hand, we need an "is" or "instanceof" operator
 then...

Nov 23 2001

↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:

Pavel Minayev wrote:

 "Walter" <walter digitalmars.com> wrote in message
 news:9tmi2t$31hm$1 digitaldaemon.com...
 
 
But all the "is" operator would do is check the cast for a null return.


 
seems redundant.


 No. My proposal is to throw an exception on bad cast
 rather than return null, to prevent further errors.




Whether we have casts return null or throw exception, it's possible
to wrap the language's standard cast in order to simulate the other
behavior. Considered from that point, it's (a) slightly easier to
have the standard cast return null and write a wrapper that throws
than vice versa[1], and (b) faster in run-time to return null than to
throw an exception.

The same argument can be made regarding memory allocation[2], of
course, or file I/O, and then we're back to testing the return
value from every function.[3]

So it really comes down to whether or not you consider throwing a
bunch of objects which have "void in common" into the same container
to be good programming practice, or no.

-RB


[1] Two ways come to mind: "if (obj == null) throw" or "obj->Method()".

[2] Which is why my memory manager offers an interface which includes
a "this allocation is non-critical, so don't work too hard, and return
NULL if you have to" flag as an option.
[3] ...the way god intended you to write code.

Nov 24 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3BFF539D.40808 estarcion.com...

 Whether we have casts return null or throw exception, it's possible
 to wrap the language's standard cast in order to simulate the other
 behavior. Considered from that point, it's (a) slightly easier to
 have the standard cast return null and write a wrapper that throws
 than vice versa[1], and (b) faster in run-time to return null than to
 throw an exception.


The problem is somewhat different. In general, I suppose that an object
to be casted should always conform to the new type, for classes at least -
what are you going to do with a wrongly-casted pointer anyhow? So
it is a deliberate error, and is supposed to never occur in a final
version of the program (dreams...). So in most cases you don't in fact
write any checking code, you just rely on it always working properly.
And when debugging the program, if the cast is wrong, you'd most likely
want to know about it - and you will if it throws an exception. On other
hand, null pointer is just silently accepted and at some later point
you get an access violation. If you do the cast in a function call, and
the function transfers it further... you could end with an exception
in some completely different module (long, long ago in a function far,
far away =)) staring on the screen and thinking, "WHAT the hell can be
wrong with this???" - well you might know the feeling....

Or maybe introduce two cast keywords - one for safe and one for unsafe
cast? Pascal syntax, maybe? LOL

Nov 24 2001

↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:

Pavel Minayev wrote:

 "Russell Borogove" <kaleja estarcion.com> wrote in message
 news:3BFF539D.40808 estarcion.com...
 
 
Whether we have casts return null or throw exception, it's possible
to wrap the language's standard cast in order to simulate the other
behavior. Considered from that point, it's (a) slightly easier to
have the standard cast return null and write a wrapper that throws
than vice versa[1], and (b) faster in run-time to return null than to
throw an exception.


 The problem is somewhat different. In general, I suppose that an object
 to be casted should always conform to the new type, for classes at least -
 what are you going to do with a wrongly-casted pointer anyhow? So
 it is a deliberate error, and is supposed to never occur in a final
 version of the program (dreams...).



I do understand your point, but some people design their code differently.

It may or may not be an error. Say we're talking about game code, and 
you're iterating over a collection of objects derived from class Entity, 
checking to see if they're castable to class ThinkingEntity, and if so, 
calling their Think() method. There are any number of good reasons to 
maintain all your entities in a single collection even though they're
not completely compatible in some contexts. The alternative is to bloat 
the base class with a bunch of virtual functions which will be no-op in 
the majority of cases. (Not to mention that sometimes you won't be 
allowed to mess with the base class.)

My point is that from a single cast-else-null primitive, you can build 
cast-else-throw and and is-safe-to-cast? operations easily and 
efficiently; if the primitive is cast-else-throw, then the 
is-safe-to-cast? operation _must_ (as you noted) be provided by the 
language in a way that doesn't internally generate an exception, for
performance reasons.

-RB

Nov 24 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3BFFFBB3.4070707 estarcion.com...

 It may or may not be an error. Say we're talking about game code, and
 you're iterating over a collection of objects derived from class Entity,
 checking to see if they're castable to class ThinkingEntity, and if so,
 calling their Think() method. There are any number of good reasons to
 maintain all your entities in a single collection even though they're
 not completely compatible in some contexts. The alternative is to bloat
 the base class with a bunch of virtual functions which will be no-op in
 the majority of cases. (Not to mention that sometimes you won't be
 allowed to mess with the base class.)


IMHO it's better to make a separate operator to check for the class.
Again, an excelent (IMHO) implementation of this is Delphi:

    Class(object)    // cast to Class, no type-check
    object as Class  // cast to Class, throw exception on error
    object is Class  // true if object is instance of Class

So to call ThinkingEntity.Think(), you'd require the following code,
supposing that "is" operator is supported in D:

    if (entity is ThinkingEntity)
        entity.Think();

Your code would look very similar:

    if (cast(ThinkingEntity) Entity)
        entity.Think();

So no real advantage here.

 My point is that from a single cast-else-null primitive, you can build
 cast-else-throw and and is-safe-to-cast? operations easily and
 efficiently; if the primitive is cast-else-throw, then the


The problem is that every cast operation must be wrapped in an if-block
to throw exceptions. This is like, say, wrapping each C function call
checking if it returns an error code and throwing an exception.

IMHO, typechecking and typecasting should be _separate_ operations,
not mixed. Because typecasting is usually performed on the generic
pointer actually pointing to the child class when you know for sure
that it does, and typechecking is used when you don't know what object
your pointer references. These are two distinct things, let's not
mix them.

 is-safe-to-cast? operation _must_ (as you noted) be provided by the
 language in a way that doesn't internally generate an exception, for
 performance reasons.


BTW I've just thought that this operation is already supported by
D due to its RTTI system:

    if (entity.class == ClassThinkingEntity)
        entity.Think();

Personally, I like the "is" operator more, but even now D already
has support for typechecking.

Nov 24 2001

↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:

Pavel Minayev wrote:

 IMHO, typechecking and typecasting should be _separate_ operations,
 not mixed. Because typecasting is usually performed on the generic
 pointer actually pointing to the child class when you know for sure
 that it does, and typechecking is used when you don't know what object
 your pointer references. These are two distinct things, let's not
 mix them.



It's possible that I've been poisoned by years of working with
functions that return a pointer or NULL on failure, but that's a
familiar way for me to frame the idiom "if object supports X() then
do X() on object," so we may just be up against personal style
issues here.


 BTW I've just thought that this operation is already supported by
 D due to its RTTI system:
 
     if (entity.class == ClassThinkingEntity)
         entity.Think();
 
 Personally, I like the "is" operator more, but even now D already
 has support for typechecking.



But we need to know if the entity is a ThinkingEntity or any class
derived from that.


The class library I'm working with at my job has two separate
operations (macros, actually) -- IsA(), which checks exact 
class membership, and IsKindOf(), which checks for membership
in any derived class. 


Those would be the minimum primitives necessary in conjunction
with a throwing cast to support the idiom.

-RB

Nov 24 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C0003D0.9070305 estarcion.com...

 It's possible that I've been poisoned by years of working with
 functions that return a pointer or NULL on failure, but that's a
 familiar way for me to frame the idiom "if object supports X() then
 do X() on object," so we may just be up against personal style
 issues here.


It's a common style that I use as well, I just ain't satisfied
with the syntax.

 But we need to know if the entity is a ThinkingEntity or any class
 derived from that.


Oh yes, I missed that. However, I'm pretty sure that classes
of classes will have some way to determine the parent, for
example:

    if (entity.class.extends(ClassThinkingEntity)) ...

Or sumthing like that. Probably Walter will tell us if this
works or not as he comes by this thread =)

 The class library I'm working with at my job has two separate
 operations (macros, actually) -- IsA(), which checks exact
 class membership, and IsKindOf(), which checks for membership
 in any derived class.

 Those would be the minimum primitives necessary in conjunction
 with a throwing cast to support the idiom.


In most cases, you actually use IsKindOf() or its equvalent.
So I believe the exact typechecking could be left in its current
form, and base class check should of course be introduced,
hopefully in form of "is" operator.

Nov 24 2001

↑ ↓ ← → "Sean L. Palmer" <spalmer iname.com> writes:

This sounds like fine syntax to me.  I still think that once you've
determined that an object is a subclass of some base class, you should be
able to do the typecast without checking the same thing again.

if (entity.class.extends(ClassThinkingEntity))
   (static_cast(ClassThinkingEntity) entity).Think();

or

(dynamic_cast(ClassThinkingEntity) entity).Think(); // dynamic_cast must
throw an exception if it can't do it.

But I'd hate to pay the RTTI lookup overhead twice.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:9trei7$euv$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:9tptu2$22je$1 digitaldaemon.com...
 "Russell Borogove" <kaleja estarcion.com> wrote in message
 news:3C0003D0.9070305 estarcion.com...
     if (entity.class.extends(ClassThinkingEntity)) ...

 Or sumthing like that. Probably Walter will tell us if this
 works or not as he comes by this thread =)


 No, I had missed that.

 It's wierd how from time to time I discover interesting things in my own
 design <g>.

Nov 29 2001

↑ ↓ ← → "Sean L. Palmer" <spalmer iname.com> writes:

 IMHO, typechecking and typecasting should be _separate_ operations,
 not mixed. Because typecasting is usually performed on the generic
 pointer actually pointing to the child class when you know for sure
 that it does, and typechecking is used when you don't know what object
 your pointer references. These are two distinct things, let's not
 mix them.


I agree with this.  Dynamic typecasting can be almost zero overhead if the
object is already known to be of such type or a descendant.

 is-safe-to-cast? operation _must_ (as you noted) be provided by the
 language in a way that doesn't internally generate an exception, for
 performance reasons.


 BTW I've just thought that this operation is already supported by
 D due to its RTTI system:

     if (entity.class == ClassThinkingEntity)
         entity.Think();

 Personally, I like the "is" operator more, but even now D already
 has support for typechecking.


Nope, that won't catch the case where entity is actually a class derived
from ClassThinkingEntity.  Maybe an 'is' operator here would be nice.  Only
takes class types as arguments (an object being implicitly convertible to
its class type)

Sean

Nov 29 2001

↑ ↓ ← → a <a b.c> writes:

	This post just gave me a thought.  It probably isn't appropriate for D
but I'll spit it out anyway.  Each type is going to have a property that
tells you the type right?  (Humor me.  Say yes.)  Likewise we could also
put such a property on the class identifier itself.  The property could
be the RTTI info.  I don't really care as long as it is a definite type
that the compiler can recognize.

	So you have:

		Class1;      // some class defined somewhere
		Class1 Obj1; // an instance of Class1
		Class2;	     // another class
		Class2 Obj2; // you know the drill

With the property I described above (I'll call it type) and some type
comparison operators we could have:

		// true iff Obj1 & Obj2 are instances 
		// of the same class
		Obj1.type == Obj2.type;

		// true iff Obj1 is a descendent of Obj2
		Obj1.type > Obj2.type;

		// true iff Obj1 is a parent of Obj2
		Obj1.type < Obj2.type;

Since classes have the property you could also say:

		// true iff Obj is an instance of Class
		Obj.type == Class.type;

You could also have all of the >=, <=, !=, <> type comparison too.  This
could be done in the compiler but I imagine the detractors of operator
overloading might also be offended by this.  It's clear (to me at least)
concise, and does require new keywords or syntax.

Thought?
Dan

"Sean L. Palmer" wrote:
 
 IMHO, typechecking and typecasting should be _separate_ operations,
 not mixed. Because typecasting is usually performed on the generic
 pointer actually pointing to the child class when you know for sure
 that it does, and typechecking is used when you don't know what object
 your pointer references. These are two distinct things, let's not
 mix them.


 I agree with this.  Dynamic typecasting can be almost zero overhead if the
 object is already known to be of such type or a descendant.
 
 is-safe-to-cast? operation _must_ (as you noted) be provided by the
 language in a way that doesn't internally generate an exception, for
 performance reasons.


 BTW I've just thought that this operation is already supported by
 D due to its RTTI system:

     if (entity.class == ClassThinkingEntity)
         entity.Think();

 Personally, I like the "is" operator more, but even now D already
 has support for typechecking.


 Nope, that won't catch the case where entity is actually a class derived
 from ClassThinkingEntity.  Maybe an 'is' operator here would be nice.  Only
 takes class types as arguments (an object being implicitly convertible to
 its class type)
 
 Sean

Nov 29 2001

↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:

a wrote:

 	So you have:
 
 		Class1;      // some class defined somewhere
 		Class1 Obj1; // an instance of Class1
 		Class2;	     // another class
 		Class2 Obj2; // you know the drill
 
 With the property I described above (I'll call it type) and some type
 comparison operators we could have:
 
 		// true iff Obj1 & Obj2 are instances 
 		// of the same class
 		Obj1.type == Obj2.type;
 
 		// true iff Obj1 is a descendent of Obj2
 		Obj1.type > Obj2.type;
 
 		// true iff Obj1 is a parent of Obj2
 		Obj1.type < Obj2.type;
 
 Since classes have the property you could also say:
 
 		// true iff Obj is an instance of Class
 		Obj.type == Class.type;
 
 You could also have all of the >=, <=, !=, <> type comparison too.  This
 could be done in the compiler but I imagine the detractors of operator
 overloading might also be offended by this.  It's clear (to me at least)
 concise, and does require new keywords or syntax.



I like it, but I will be perpetually confused because I'll think of
parents as "greater than" children, or see the > as a directional
indicator of the direction of descendance instead of the direction
of inheritance.

Also, it's unclear what the right answers are when obj1 and obj2
are completely unrelated classes -- probably all relationals should
return false?

-RB

Nov 29 2001

↑ ↓ ← → a <a b.c> writes:

Russell Borogove wrote:
 
 a wrote:
 
       So you have:

               Class1;      // some class defined somewhere
               Class1 Obj1; // an instance of Class1
               Class2;      // another class
               Class2 Obj2; // you know the drill

 With the property I described above (I'll call it type) and some type
 comparison operators we could have:

               // true iff Obj1 & Obj2 are instances
               // of the same class
               Obj1.type == Obj2.type;

               // true iff Obj1 is a descendent of Obj2
               Obj1.type > Obj2.type;

               // true iff Obj1 is a parent of Obj2
               Obj1.type < Obj2.type;

 Since classes have the property you could also say:

               // true iff Obj is an instance of Class
               Obj.type == Class.type;

 You could also have all of the >=, <=, !=, <> type comparison too.  This
 could be done in the compiler but I imagine the detractors of operator
 overloading might also be offended by this.  It's clear (to me at least)
 concise, and does require new keywords or syntax.


 I like it, but I will be perpetually confused because I'll think of
 parents as "greater than" children, or see the > as a directional
 indicator of the direction of descendance instead of the direction
 of inheritance.


	I saw it as meaning the child class was everything the parent was and
more.  A superset of sorts.  However, swapping the operators probably
wouldn't hurt.  It would just have to have a good meaning that capture
the inheritance relation and how the parent is 'greater'.  (Age doesn't
count.)

 Also, it's unclear what the right answers are when obj1 and obj2
 are completely unrelated classes -- probably all relationals should
 return false?


	I guess I was thinking of that as being treated like the NaN cases with
floats.  They aren't equal and neither one is greater than the other. 
Isn't there a difference between != and <> for floats?

Dan

Nov 29 2001