Dynamic alter-ego of D.

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Tue Oct 25 08:39:03 PDT 2011


That's the point. You don't always need to carry around your type.
Also because you might do it in a specific and very efficient way.
Imposing a single way of storing the type is a very inflexible decision.
The type check may also be done at different points, after which it's
not necessary to carry around.
Also, as i said before, type checking WILL be done in debug mode and
dropped in release mode.
Variant could be built on that typeless value concept to ensure type
safety at all times.

On Tue, Oct 25, 2011 at 7:33 PM, Robert Jacques <sandford at jhu.edu> wrote:
> On Tue, 25 Oct 2011 09:23:10 -0400, Gor Gyolchanyan
> <gor.f.gyolchanyan at gmail.com> wrote:
>>
>> I need an extremely fast and small typeless container for a single
>> object, which i can use to implement a fast and efficient dynamic
>> callback mechanism, where the exact number and types of parameters are
>> only known to the callback and to the source of the parameter values
>> and all intermediate manager classes, who hold and return the callback
>> do not know it.
>>
>> On Tue, Oct 25, 2011 at 5:20 PM, Gor Gyolchanyan
>> <gor.f.gyolchanyan at gmail.com> wrote:
>>>
>>> Variant is heavy. It contains and does lots of things, that are not
>>> always required.
>>> a tiny type-less variable is versatile and can be used for any
>>> purposes. It's even type-safe in debug mode.
>>> Also, Variant needs explicit construction, whereas the tiny typeless
>>> variable automatically accepts any value.
>>> Also, Variant does not grant access to underlying raw data, but tiny
>>> typeless value can be taken address of (void*).
>
> Just because something is feature-full, doesn't make it heavy weight. But I
> guess over a raw tagged-union with a limited interface, it would be
> considered heavy. But, I don't understand you concept of a type-less
> variable. Truly type-less variables don't exist in any language; you always
> have a pluripotent dynamic type like variant under the hood.
>


More information about the Digitalmars-d mailing list