[sv-bc] Re: [sv-ec] $typename follow-up

-----Non-member submission-----
On Behalf Of Michael Burns
Sent: Thursday, June 22, 2006 4:02 PM

Ah - yes, comparing two strings returned from $typename() addresses my 
concern. Your scenario with associative arrays could be made to work by 
dynamically initializing the array and accessing the array only using 
strings returned from $typename() as keys.

Thanks,
Mike

Gordon Vreugdenhil wrote:
> 
> 
> Michael Burns wrote:
> 
>>
>> Hi Gordon,
>>
>> Yeah, exact portability is a dream. Isn't it a nice one, though?
>>
>> Anyways, the case I was concerned about was the one Brad raised,
where 
>> useing $typename was the only way to distinguish between a packed 
>> array and an integer. I'm thinking about code like this:
>>
>> if ($typename(foo) == "integer")
>>   // do something
>> else if ($typename(foo) == "packed array")
>>   // do something else
>>
>> What I'm now having trouble doing is thinking of what foo might be; 
>> could it refer to a type parameter of a class:
>>
>> class Foo #(type T = int);
>>  T foo;
>> ...
>>  if ($typename(foo) == "integer")
> 
> 
> 
> Wouldn't this more safe (and likely more efficient) if you did:
>    if (type(foo) == type(integer))
> This is "true" for any matching type of integer.  The only
> case in which $typename would differ is if "foo" was an
> equivalent type rather than matching (in which case "typename"
> is actually weaker which is an odd reversal in the spec).
> 
> 
> There aren't many realistic situations that I can think of in which
> one would need to distinguish between two types and where
> the matching aspect of type() comparison wouldn't be sufficient.
> It seems to me that such comparisons are much less error prone.
> 
> General uses of $typename in the manner that you have above
> would require a *very* tight definition of $typename.  As
> one example, what if I did:
>     Foo #(Foo #( integer ))
> The names of the inner type would have to be completely defined
> in the spec (down to spacing, etc).
> 
> I can see a possible scenario in which one wanted a associative
> array (or similar) mapping from type -> class (or value).  Since
> the result of "type" isn't a value that you can capture,
> $typename could be useful there.  But if that is the kind of
> use model, I would rather have a "type_id" that generates
> a unique integral value for a type rather than relying on
> a string match.  If we really want to make all of this robust,
> we probably should have a family of type operations:
>    type_to_id(t)          // yields a unique integral type id
>    id_to_type(t)          // yields the type (so that the following
work)
>    type_match(t1,t2)
>    type_equivalent(t1,t2)
>    type_assignable(t1,t2)
> 
> This would at least explicitly expose the type calculus rather
> than having ad hoc pieces be exposed as is the case now.
> 
> Gord