View mode: basic / threaded / horizontal-split · Log in · Help
October 20, 2011
Re: typeof()
J Arrizza wrote:
> typeof returns the type of the object given to it:
> 
>     SomeClass sc;
>     typeof(sc)  // returns SomeClass
> 
>     Object o = sc;
>     typeof(o) // returns Object
> 
> Is there a way or call to get the underlying type?:
> 
>     typeof2(o) //returns SomeClass
> 
> I checked the online doc, but nothing in the Declarations section that I
> could see.

typeid should work.
http://d-programming-language.org/expression.html#TypeidExpression

Jens
October 20, 2011
Re: typeof()
Maybe I'm doing something else incorrectly:

class Base
 {
   public void inBase()
     {
     }
 }

class Bob : Base
 {
   public void inBob()
     {
     }
 }


   Bob bob = new Bob();
   writeln("Bob as Bob");
   foreach (i, m; __traits(allMembers, typeof(bob)))
     {
       writeln("=== i=", i, "  m=", m);
     }

   Base base = bob;
   writeln("Bob as Base");
   foreach (i, m; __traits(allMembers, typeof(base)))
     {
       writeln("=== i=", i, "  m=", m);
     }

The output is:

Bob as Bob
=== i=0  m=inBob
=== i=1  m=inBase
=== i=2  m=toString
=== i=3  m=toHash
=== i=4  m=opCmp
=== i=5  m=opEquals
=== i=6  m=Monitor
=== i=7  m=factory
Bob as Base
=== i=0  m=inBase     ; missing inBob()
=== i=1  m=toString
=== i=2  m=toHash
=== i=3  m=opCmp
=== i=4  m=opEquals
=== i=5  m=Monitor
=== i=6  m=factory



If typeof(base) returned Bob as the type, then the two lists of members
should be identical. Or am I missing something else?

If I  use derivedMembers instead of allMembers, the output is:

Bob as Bob
=== i=0  m=inBob
Bob as Base
=== i=0  m=inBase


which still seems to support that typeof() doesn't return the underlying
type.

John


On Thu, Oct 20, 2011 at 12:25 AM, Jens Mueller <jens.k.mueller@gmx.de>wrote:

> J Arrizza wrote:
> > typeof returns the type of the object given to it:
> >
> >     SomeClass sc;
> >     typeof(sc)  // returns SomeClass
> >
> >     Object o = sc;
> >     typeof(o) // returns Object
> >
> > Is there a way or call to get the underlying type?:
> >
> >     typeof2(o) //returns SomeClass
> >
> > I checked the online doc, but nothing in the Declarations section that I
> > could see.
>
> typeid should work.
> http://d-programming-language.org/expression.html#TypeidExpression
>
> Jens
>



-- 
John
blog: http://arrizza.blogspot.com/
web: http://www.arrizza.com/
October 20, 2011
Re: typeof()
On Thu, 20 Oct 2011 09:46:09 -0400, J Arrizza <cppgent0@gmail.com> wrote:

> Maybe I'm doing something else incorrectly:
>
[snip]
>
> which still seems to support that typeof() doesn't return the underlying
> type.

typeid is not typeof.  Reread the response below.

However, note that typeid returns a TypeInfo object, which is used at  
runtime, not at compile time.  D's runtime type info is very limited, so  
you may not be able to get what you are looking for.

-Steve

>
> On Thu, Oct 20, 2011 at 12:25 AM, Jens Mueller  
> <jens.k.mueller@gmx.de>wrote:
>
>> J Arrizza wrote:
>> > typeof returns the type of the object given to it:
>> >
>> >     SomeClass sc;
>> >     typeof(sc)  // returns SomeClass
>> >
>> >     Object o = sc;
>> >     typeof(o) // returns Object
>> >
>> > Is there a way or call to get the underlying type?:
>> >
>> >     typeof2(o) //returns SomeClass
>> >
>> > I checked the online doc, but nothing in the Declarations section  
>> that I
>> > could see.
>>
>> typeid should work.
>> http://d-programming-language.org/expression.html#TypeidExpression
>>
>> Jens
>>
>
>
October 20, 2011
Re: typeof()
> 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.
October 20, 2011
Re: typeof()
Of course. that's why it's called "run-time" type info.
This is why i want a python-like duck typing support in Phobos.
No, variant won't do, it's for a completely different purpose.
It would be a single class, which represents any Object and would have
an opDispatch, which would redirect the calls to the underlying object
or throw an exception if the call is invalid.

On Thu, Oct 20, 2011 at 6:13 PM, Steven Schveighoffer
<schveiguy@yahoo.com> 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 if what you need is run time type info (like information about the
> derived class of a concrete base reference), then you cannot use
> compile-time type info.
>
> -Steve
>
October 20, 2011
Re: typeof()
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
October 20, 2011
Re: typeof()
Agreed. The explicit and selective rtti would be great. Sometimes i
need to create classes instead of structs because the reference
semantics is more applicable, but i don't want to carry around type
information, that I'm not gonna use.

On Thu, Oct 20, 2011 at 6:20 PM, Steven Schveighoffer
<schveiguy@yahoo.com> 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
>
October 20, 2011
Re: typeof()
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.

-- 
/Jacob Carlborg
October 20, 2011
Re: typeof()
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
October 21, 2011
Re: typeof()
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
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home