Jump to page: 1 2 3
Thread overview
Re: typeof()
Oct 20, 2011
Jens Mueller
Oct 22, 2011
Walter Bright
Oct 20, 2011
J Arrizza
Oct 20, 2011
Gor Gyolchanyan
Oct 20, 2011
Gor Gyolchanyan
Oct 20, 2011
Gor Gyolchanyan
Oct 20, 2011
Jacob Carlborg
Oct 21, 2011
Jacob Carlborg
Oct 21, 2011
Gor Gyolchanyan
Oct 21, 2011
Marco Leise
Oct 21, 2011
Gor Gyolchanyan
Oct 21, 2011
Jacob Carlborg
Oct 21, 2011
Jacob Carlborg
Oct 21, 2011
Jacob Carlborg
Oct 22, 2011
Jacob Carlborg
Oct 24, 2011
Jacob Carlborg
Oct 21, 2011
Jacob Carlborg
Oct 23, 2011
J Arrizza
October 20, 2011
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
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
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
> 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
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
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
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
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
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
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