typeof()

[Jacob Carlborg]

On 2011-10-21 16:17, Steven Schveighoffer wrote:
> On Fri, 21 Oct 2011 08:07:57 -0400, Jacob Carlborg <doob at me.com> wrote:
>
>> 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.
>
> Do you have access to the methods via RTTI? I thought only the default
> ctor was accessible (and some other special methods such as opCmp, but
> those are hacks).

No. But later in the deserialization process I have access to the 
compile-time type. Then I can cast the object to the correct type and 
check which methods are available.

Note that TypeInfo/ClassInfo have methods for accessing the members of 
an object but it's not implemented. The returned array of members is 
always empty, the compiler doesn't output the any information.

It would be possible to generate RTTI via compile time reflection to be 
able to access methods via RTTI.

> I admit I don't use RTTI enough to know what's available, you obviously
> have a better understanding of the state of things.
>
>>
>>> 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.
>
> This can still be done. If you have the compile-time type you can always
> forcefully generate the run time info (I would expect such a feature
> when RTTI is fully developed).

The thing is that you may not have access to the compile-time type, i.e. :

class Base {}
class Sub : Base {}

Base sub = new Sub;

Now the compile-time information specific for Sub is gone when accessing 
"sub".

I have this problem with my serialization library. To workaround this 
the user have to register the compile-time type with the serializer to 
be able to (de)serialize via base class references.

> If they don't specify the @rtti attribute, then perhaps the class isn't
> meant to be accessed via RTTI
>
> My thoughts were, you'd specify @rtti on the base class of a hierarchy
> that you need to use RTTI on, and all derived classes would generate info.
>
> In any case, I'm not looking to define the exact features, I'm just
> saying I think it could work as an opt-in attribute.
>
> -Steve

Ok, I see.

-- 
/Jacob Carlborg