October 22, 2011
On 2011-10-21 17:19, Steven Schveighoffer wrote:
> 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

If I can make it work without specifying an attribute on a class why shouldn't I. One thing less to think about. It's just in this special case the type needs to registered with the serializer.

-- 
/Jacob Carlborg
October 22, 2011
On 10/20/2011 12:25 AM, Jens Mueller 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.

typeof2 would have to work at runtime, meaning it cannot participate in static type checking, or template expansion, etc.
October 23, 2011
Thanks. I tried typeid vs typeof and as you pointed out the runtime vs compile time info isn't what I need.

On Thu, Oct 20, 2011 at 6:55 AM, Steven Schveighoffer <schveiguy@yahoo.com>wrote:

> 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<http://d-programming-language.org/expression.html#TypeidExpression>
>>>
>>> Jens
>>>
>>>
>>
>>


-- 
John
blog: http://arrizza.blogspot.com/
web: http://www.arrizza.com/


October 24, 2011
On Sat, 22 Oct 2011 08:00:50 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2011-10-21 17:19, Steven Schveighoffer wrote:
>> 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
>
> If I can make it work without specifying an attribute on a class why shouldn't I. One thing less to think about. It's just in this special case the type needs to registered with the serializer.

Serialization requires metadata about the datatypes being serialized.  If I don't want to serialize something, why should I have to pay the bloat cost of being *able to* when I never actually do?

I don't mind registering data types with the serializer that need to be serialized.  I know it would be nicer from a serializer library writer's perspective to just say everything is serializable, but I'd rather have D be efficient when it needs to be instead of trying to support every possible use case no matter how uncommon.  Again, when I serialize things, I typically am in control of those data types.  I have not yet had a case where an *opaque* data type that needed to be serialized wasn't one that I wrote myself.

And I wrote an entire system in C# that used remoting exclusively for client-server communication.  Every data type that needed to be used for remoting must be serializable.

-Steve
October 24, 2011
On 2011-10-24 15:49, Steven Schveighoffer wrote:
> On Sat, 22 Oct 2011 08:00:50 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2011-10-21 17:19, Steven Schveighoffer wrote:
>>> 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
>>
>> If I can make it work without specifying an attribute on a class why
>> shouldn't I. One thing less to think about. It's just in this special
>> case the type needs to registered with the serializer.
>
> Serialization requires metadata about the datatypes being serialized. If
> I don't want to serialize something, why should I have to pay the bloat
> cost of being *able to* when I never actually do?

I don't have a good answer. In some cases one wants to have runtime reflection and in other cases that just causes bloat.

BTW, in general, serialization doesn't not require metadata, only when serializing through base class references.

> I don't mind registering data types with the serializer that need to be
> serialized. I know it would be nicer from a serializer library writer's
> perspective to just say everything is serializable, but I'd rather have
> D be efficient when it needs to be instead of trying to support every
> possible use case no matter how uncommon. Again, when I serialize
> things, I typically am in control of those data types. I have not yet
> had a case where an *opaque* data type that needed to be serialized
> wasn't one that I wrote myself.
>
> And I wrote an entire system in C# that used remoting exclusively for
> client-server communication. Every data type that needed to be used for
> remoting must be serializable.
>
> -Steve


-- 
/Jacob Carlborg
1 2 3
Next ›   Last »