template Thing(T)
{
    class Thing
    {
    private:
        const char[] sm_componentName = "Thing";

    }
}

This means that I can use the componentName in mixins, member templates, member functions (virtual or static), etc. for the construction of meaningful exception reports.

However, it occured to me that it might also be desirable to get hold of a stringized form of the parameterisation. Naturally, this could not be a manual thing any longer, so what do we all think about some compile time function stringize(T) where T is a type, rather than a value. It would look like the following:

    const char[] stringize(T)

The return value would be a slice onto the same string literal inserted into the link-unit (dyn lib / exe) by the linker. We'd have to live with it being link-unit-local, as there's no practical way to make it be constant across link-units. (At least non that I can think of.) But that's not really a problem, as I can't think of any reason to want to use this for determining type identity, not when we have the typeof keyword.

Matthew wrote:

>template Thing(T)
>{
>    class Thing
>    {
>    private:
>        const char[] sm_componentName = "Thing";
>
>    }
>}
>
>This means that I can use the componentName in mixins, member templates, member
>functions (virtual or static), etc. for the construction of meaningful exception
>reports.
>
>However, it occured to me that it might also be desirable to get hold of a
>stringized form of the parameterisation. Naturally, this could not be a manual
>thing any longer, so what do we all think about some compile time function
>stringize(T) where T is a type, rather than a value. It would look like the
>following:
>
>    const char[] stringize(T)
>
>The return value would be a slice onto the same string literal inserted into the
>link-unit (dyn lib / exe) by the linker. We'd have to live with it being
>link-unit-local, as there's no practical way to make it be constant across
>link-units. (At least non that I can think of.) But that's not really a problem,
>as I can't think of any reason to want to use this for determining type identity,
>not when we have the typeof keyword.
>

If I understand you correctly, you want to get the string type from the type.  You can already do something like this using templates.

template stringize(T : bit) { char [] name() { return "bit"; } }
template stringize(T : byte) { char [] name() { return "byte"; } }

//Of course then you've got array types ect... but it could all be put into a standard lib.

use:
char [] name = stringize!(T).name();

You probably already knew that, I'm probably talking about something completely different.  Why did I say anything <g>

-- 
-Anderson: http://badmama.com.au/~anderson/

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c7i671$e8q$1@digitaldaemon.com...
> Matthew wrote:
>
> >template Thing(T)
> >{
> >    class Thing
> >    {
> >    private:
> >        const char[] sm_componentName = "Thing";
> >
> >    }
> >}
> >
> >This means that I can use the componentName in mixins, member templates,
member
> >functions (virtual or static), etc. for the construction of meaningful
exception
> >reports.
> >
> >However, it occured to me that it might also be desirable to get hold of a stringized form of the parameterisation. Naturally, this could not be a manual thing any longer, so what do we all think about some compile time function stringize(T) where T is a type, rather than a value. It would look like the following:
> >
> >    const char[] stringize(T)
> >
> >The return value would be a slice onto the same string literal inserted into
the
> >link-unit (dyn lib / exe) by the linker. We'd have to live with it being link-unit-local, as there's no practical way to make it be constant across link-units. (At least non that I can think of.) But that's not really a
problem,
> >as I can't think of any reason to want to use this for determining type
identity,
> >not when we have the typeof keyword.
> >
>
> If I understand you correctly, you want to get the string type from the type.  You can already do something like this using templates.
>
> template stringize(T : bit) { char [] name() { return "bit"; } }
> template stringize(T : byte) { char [] name() { return "byte"; } }
>
> //Of course then you've got array types ect... but it could all be put into a standard lib.
>
> use:
> char [] name = stringize!(T).name();
>
> You probably already knew that, I'm probably talking about something completely different.  Why did I say anything <g>

:)

It's easy, although tedious, to specialise templates for known types, but a template can, in principle, have an infinite number of specialisations. Hence, specialisation cannot be the answer. I need something only the language/compiler can provide.

Matthew wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:c7i671$e8q$1@digitaldaemon.com...
>  
>
>>Matthew wrote:
>>
>>    
>>
>>>template Thing(T)
>>>{
>>>   class Thing
>>>   {
>>>   private:
>>>       const char[] sm_componentName = "Thing";
>>>
>>>   }
>>>}
>>>
>>>This means that I can use the componentName in mixins, member templates,
>>>      
>>>
>member
>  
>
>>>functions (virtual or static), etc. for the construction of meaningful
>>>      
>>>
>exception
>  
>
>>>reports.
>>>
>>>However, it occured to me that it might also be desirable to get hold of a
>>>stringized form of the parameterisation. Naturally, this could not be a manual
>>>thing any longer, so what do we all think about some compile time function
>>>stringize(T) where T is a type, rather than a value. It would look like the
>>>following:
>>>
>>>   const char[] stringize(T)
>>>
>>>The return value would be a slice onto the same string literal inserted into
>>>      
>>>
>the
>  
>
>>>link-unit (dyn lib / exe) by the linker. We'd have to live with it being
>>>link-unit-local, as there's no practical way to make it be constant across
>>>link-units. (At least non that I can think of.) But that's not really a
>>>      
>>>
>problem,
>  
>
>>>as I can't think of any reason to want to use this for determining type
>>>      
>>>
>identity,
>  
>
>>>not when we have the typeof keyword.
>>>
>>>      
>>>
>>If I understand you correctly, you want to get the string type from the
>>type.  You can already do something like this using templates.
>>
>>template stringize(T : bit) { char [] name() { return "bit"; } }
>>template stringize(T : byte) { char [] name() { return "byte"; } }
>>
>>//Of course then you've got array types ect... but it could all be put
>>into a standard lib.
>>
>>use:
>>char [] name = stringize!(T).name();
>>
>>You probably already knew that, I'm probably talking about something
>>completely different.  Why did I say anything <g>
>>    
>>
>
>:)
>
>It's easy, although tedious, to specialise templates for known types, but a
>template can, in principle, have an infinite number of specialisations. Hence,
>specialisation cannot be the answer. I need something only the language/compiler
>can provide.
>  
>
Parhaps a recursive template is the answer.

-- 
-Anderson: http://badmama.com.au/~anderson/

Matthew wrote:

> template Thing(T)
> {
>     class Thing
>     {
>     private:
>         const char[] sm_componentName = "Thing";
> 
>     }
> }
> 
> This means that I can use the componentName in mixins, member templates, member
> functions (virtual or static), etc. for the construction of meaningful exception
> reports.
> 
> However, it occured to me that it might also be desirable to get hold of a
> stringized form of the parameterisation. Naturally, this could not be a manual
> thing any longer, so what do we all think about some compile time function
> stringize(T) where T is a type, rather than a value. It would look like the
> following:
> 
>     const char[] stringize(T)
> 
> The return value would be a slice onto the same string literal inserted into the
> link-unit (dyn lib / exe) by the linker. We'd have to live with it being
> link-unit-local, as there's no practical way to make it be constant across
> link-units. (At least non that I can think of.) But that's not really a problem,
> as I can't think of any reason to want to use this for determining type identity,
> not when we have the typeof keyword.

You can get pretty close with templates:

template stringize(T : bit)
{ char[] stringize() { return "bit"; } }
// yadda yadda for all primitive types

template stringize(T : Object)
{ char[] stringize() { return T.classinfo.name; } }
template stringize(T : T[])
{ char[] stringize() { return .stringize!(T) ~ "[]"; } }
template stringize(T, U : T[U]) // is this syntax correct?
{ char[] stringize() { return
    .stringize!(T)() ~ "[" ~ .stringize!(U) ~ "]";
} }

// if it doesn't match anything above, it must be a struct
template stringize(T) {
    char[] stringize() { return "some struct I dunno"; }
}

(excuse the horrid use of whitespace)

That last bit suggests that it's not quite right, but it's pretty close!  A 'name' property on structs would seal it.

 -- andy

"Andy Friesen" <andy@ikagames.com> wrote in message news:c7j26i$1lvi$1@digitaldaemon.com...
> Matthew wrote:
>
> > template Thing(T)
> > {
> >     class Thing
> >     {
> >     private:
> >         const char[] sm_componentName = "Thing";
> >
> >     }
> > }
> >
> > This means that I can use the componentName in mixins, member templates,
member
> > functions (virtual or static), etc. for the construction of meaningful
exception
> > reports.
> >
> > However, it occured to me that it might also be desirable to get hold of
a
> > stringized form of the parameterisation. Naturally, this could not be a
manual
> > thing any longer, so what do we all think about some compile time
function
> > stringize(T) where T is a type, rather than a value. It would look like
the
> > following:
> >
> >     const char[] stringize(T)
> >
> > The return value would be a slice onto the same string literal inserted
into the
> > link-unit (dyn lib / exe) by the linker. We'd have to live with it being link-unit-local, as there's no practical way to make it be constant
across
> > link-units. (At least non that I can think of.) But that's not really a
problem,
> > as I can't think of any reason to want to use this for determining type
identity,
> > not when we have the typeof keyword.
>
> You can get pretty close with templates:
>
> template stringize(T : bit)
> { char[] stringize() { return "bit"; } }
> // yadda yadda for all primitive types
>
> template stringize(T : Object)
> { char[] stringize() { return T.classinfo.name; } }
> template stringize(T : T[])
> { char[] stringize() { return .stringize!(T) ~ "[]"; } }
> template stringize(T, U : T[U]) // is this syntax correct?

i was just wondering how to do that because i'm trying
to write a IsAssociativeArray template and this syntax is compiled
but it doesn't work.
I have
template IsAssociativeArray (T,U : T[U])
{
    bit IsAssociativeArray = true;
}
template IsAssociativeArray (T)
{
    bit IsAssociativeArray = false;
}

but what ever type i pass to this template the result is allways false. Maybe a bug?

> { char[] stringize() { return
>      .stringize!(T)() ~ "[" ~ .stringize!(U) ~ "]";
> } }
>
> // if it doesn't match anything above, it must be a struct
> template stringize(T) {
>      char[] stringize() { return "some struct I dunno"; }
> }
>
> (excuse the horrid use of whitespace)
>
> That last bit suggests that it's not quite right, but it's pretty close!
>   A 'name' property on structs would seal it.
>
>   -- andy