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