On 2011-10-21 16:17, Steven Schveighoffer wrote:
On Fri, 21 Oct 2011 08:07:57 -0400, Jacob Carlborg <d...@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.gyolchan...@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 <d...@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
