Traits

[luminousone]

On Saturday, 12 October 2013 at 07:47:18 UTC, Jonathan M Davis 
wrote:
> On Saturday, October 12, 2013 09:32:09 luminousone wrote:
>> And again, the casting solution is a bloody hack, it is loaded
>> with corner cases that will break things if you are not aware 
>> of
>> them. It also requires an allocated instance of that object
>
> Of course, it requires an instance of the object. The point is 
> to test whether
> an instance is of a type derived from a particular type, not 
> whether a
> particular type is derived from a particular type. If the OP 
> wants to test
> whether a particular type is derived from another type, then 
> casting is not
> the right solution. The way to do that is to use an is 
> expression, e.g.
> is(Derived : Base). If you really care that the type is a 
> derived type and
> want to avoid any other type of implicit conversions, then you 
> need to use
> some compile time reflection to do that, but that's often 
> overkill and
> completely kills the ability to create class which "inherits" 
> via alias this,
> which is the main purpose for alias this existing in the first 
> place.
>
>> It is bad practice.
>
> It's standard practice. Both the online docs and TDPL will tell 
> you to use a
> cast to determine whether a particular object's type is derived 
> from a
> particular type. And I completely disagree that it's bad 
> practice, but clearly
> we're not going to agree on that.
>
> - Jonathan M Davis

1.

opCast, and alias can break the cast approach. You pointed this 
out yourself.

2.

The requested function is testing types not instance state.

bool instanceOf(A,B)( B value ) {
         assert( value !is null );
         return inheritsFrom(A,typeof(value));
}

3.

Cast breaks on null, so this must be checked on every call, and 
leads to a 3 state outcome, true, false, and null, null then 
returns false, which is potentially incorrect and could cause odd 
bugs hard to trace.

Again it is bad practice regardless of what any document says.