October 21, 2011
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.

On Fri, Oct 21, 2011 at 10:29 AM, Jacob Carlborg <doob@me.com> wrote:
> On 2011-10-20 19:36, Steven Schveighoffer wrote:
>>
>> On Thu, 20 Oct 2011 12:26:29 -0400, Jacob Carlborg <doob@me.com> wrote:
>>
>>> On 2011-10-20 16:20, Steven Schveighoffer wrote:
>>>>
>>>> On Thu, 20 Oct 2011 10:07:12 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>>>>
>>>>>> D's runtime type info is very limited, so you may not be able to get what you are looking for.
>>>>>
>>>>> D's compile-time type info is very rich and it's easy to remember it for run-time use.
>>>>
>>>> Yes, but you have to do some funky stuff to link it to the typeinfo. Compare this to other languages where the compiler generates a very rich set of runtime info (e.g. Java).
>>>>
>>>> I think actually, the runtime info generated by the compiler is seldom used (except for maybe dynamic casting), and just creates bloat.
>>>>
>>>> I envision in the future, the runtime info generated would be triggered by an annotation like @rtti("functions", "fields", "inheritance"). That would give us a good hook to selectively generate rtti when it makes sense.
>>>>
>>>> -Steve
>>>
>>> And the you get big problems when you want to use the runtime info of a type you don't control and it doesn't use that attribute.
>>
>> Big problems being, things are null? So? Right now, there's almost no RTTI, and we do just fine.
>>
>> -Steve
>
> 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.
>
> --
> /Jacob Carlborg
>
October 21, 2011
Am 21.10.2011, 09:20 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>:

> 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.

As far as I know that is just what the programmer sees. If the compiler can verify that the method doesn't need to be virtual it will make it static by default. In terms of RTTI it would resemble to "add RTTI to a type only when we cannot be sure it isn't needed".
October 21, 2011
Automatic removal of RTTI (as well as automatic removal if method
virtuality) could have very unpleasant effects in modular
architectures.
Consider this use case:

// Base.dll

class Base
{
    string method() { return "Base"; }
}

// Derived.dll

class Derived: Base
{
    string method() { return "Derived"; }
}

Base baseFactory()
{
    return new Drived;
}

// Main.exe

export Base createBase

void main()
{
    Base b = baseFactory();
    writeln(b.method());
}

When compiling Base.dll, the compiler doesn't see any class deriving
from it, so it can remove the method from vtbl,
In that case a Base. returned from Base.dll would be a completely
different class, then a Base, returned from Derived.dll, since their
vtbl would differ. This would lead to major problems with functions,
expecting a certain ABI, but getting a different ABI.
This is an unnecessary inconsistency. marking methods as final is
purely optimization technique in this case and performance should
never cost consistency.
The compiler could emit recommendations about potentially inconsistent
optimizations.

On Fri, Oct 21, 2011 at 11:35 AM, Marco Leise <Marco.Leise@gmx.de> wrote:
> Am 21.10.2011, 09:20 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>:
>
>> 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.
>
> As far as I know that is just what the programmer sees. If the compiler can verify that the method doesn't need to be virtual it will make it static by default. In terms of RTTI it would resemble to "add RTTI to a type only when we cannot be sure it isn't needed".
>
October 21, 2011
On Fri, 21 Oct 2011 03:20:09 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@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@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.

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
October 21, 2011
On 2011-10-21 09:20, Gor Gyolchanyan 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 would like some more runtime reflection capabilities as well. It would be useful for serialization, be able to do something like this:

auto foo = new Foo;
auto cls = foo.classinfo;

foreach (f ; cls.fields)
{
    writeln(f.name);
    f.set = "some value";
    writeln(f.get);
}

This wouldn't hurt as well:

foreach (m ; cls.methods)
{
    writeln(f.name);
    f("some value");
}

foo.send("bar", "some value");

-- 
/Jacob Carlborg
October 21, 2011
On 2011-10-21 09:35, Marco Leise wrote:
> Am 21.10.2011, 09:20 Uhr, schrieb Gor Gyolchanyan
> <gor.f.gyolchanyan@gmail.com>:
>
>> 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.
>
> As far as I know that is just what the programmer sees. If the compiler
> can verify that the method doesn't need to be virtual it will make it
> static by default. In terms of RTTI it would resemble to "add RTTI to a
> type only when we cannot be sure it isn't needed".

Currently DMD doesn't do any devirtualization IIRC but I get your point.

-- 
/Jacob Carlborg
October 21, 2011
On 2011-10-21 13:07, Steven Schveighoffer wrote:
> On Fri, 21 Oct 2011 03:20:09 -0400, Gor Gyolchanyan
> <gor.f.gyolchanyan@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@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
October 21, 2011
On Fri, 21 Oct 2011 08:07:57 -0400, Jacob Carlborg <doob@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@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@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).

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).

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
October 21, 2011
On 2011-10-21 16:17, Steven Schveighoffer wrote:
> On Fri, 21 Oct 2011 08:07:57 -0400, Jacob Carlborg <doob@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@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@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
October 21, 2011
On Fri, 21 Oct 2011 10:54:47 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2011-10-21 16:17, Steven Schveighoffer wrote:

>> 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.

Well, .NET requires you to put an attribute on a class to allow it to be serializable.  And that doesn't seem to get in the way of .NET code that uses serialization.

-Steve