typeof()

Jacob Carlborg doob at me.com
Fri Oct 21 05:07:57 PDT 2011


On 2011-10-21 13:07, Steven Schveighoffer wrote:
> On Fri, 21 Oct 2011 03:20:09 -0400, Gor Gyolchanyan
> <gor.f.gyolchanyan at gmail.com> wrote:
>
>> Actually, the best idea would be to enable full reflection (much more
>> complete, then what we have now) by default and allow to remove it on
>> demand.
>> Just like the methods being virtual by default, but with ability to
>> make them final.
>
> I disagree.
>
> 1. Virtual methods are more common than final ones. But in D, RTTI is
> much less prevalent than CTTI.
> 2. RTTI can be generated from CTTI, so if you want to *force* extended
> RTTI on objects that don't declare their RTTI "filled out", it should be
> possible.
>
>>
>> On Fri, Oct 21, 2011 at 10:29 AM, Jacob Carlborg <doob at me.com> wrote:
>>
>>> I got the impression that you suggested that the current RTTI should be
>>> removed and only be available if you're using the @rtti attribute.
>
> The current RTTI is pretty useless. The only true RTTI functions in
> existence are the factory method (which is useless for classes without a
> default ctor) and dynamic cast. Everything else in TypeInfo is easily
> had with CTTI.

It's useful, I use it in my serialization library Orange. I have my own 
implementation that doesn't care about constructors. It's used for 
deserialization, instead of the constructor a special method can be used.

> I think we need dynamic casting for sure, and the nature of how classes
> are built requires it anyways. factory I'm not so sure we need to be
> supported for every class. I'd rather get full RTTI info for hierarchies
> that I'm going to use RTTI on (usually RTTI is used on a specific subset
> of the types). Yes, it does not allow for certain types of tools or
> scripting engines, but so what? If you want you can mark Object with
> @rtti and get every class into RTTI.
>
> -Steve

The problem is when you use third party types and they haven't used the 
@rtti attribute.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list