Pyd: Wrapping too many functions in a class gives a compilererror

[BCS]

Reply to Kirk,

> BCS wrote:
> 
>> Reply to Pragma,
>> 
>>> The problem is that the overly long template symbols are needed to
>>> allow the linker to do it's job: expunge redundant symbol
>>> definitions while locating the correct match for a dependency.  As
>>> the properties of a template instance is defined by its arguments,
>>> you really can't separate the two.  Combined, you get both run-time
>>> and link-time behaviors that depend heavily on the naming spec
>>> staying right where it is.  Change the spec, and you allow for false
>>> matches that can really screw things up.
>>> 
>> What is the chance of a hash coalition if all (and only) over length
>> symbols are named by a hash code that is as long as /will/ fit?
>> 
>> Alternately (and this will only work with single run compilation or
>> with external meta data) name everything with GUIDs.
>> 
>> Unless I am mistaken, really the only thing that is needed is that
>> some unique name is assigned to each instance in a way that will let
>> other stuff find the same name from the same input.
>> 
> This sounds about right. However, I predict it would be useful if the
> unique name were generated in some way which is reversible, or at
> least partly reversible. (As opposed to an MD5 hash; we hardly need
> this to be secure, after all. Not that MD5 is all that secure, these
> days...) It may aid the debugging of obscure linker errors.
> 
> Either way, this sounds like a magic bullet for these problems with
> Pyd, and any other library which abuses tuples as egregiously as it
> does.
> 

It's not totaly automatic but you could have DMD dump a *.smap file that 
lists the used name followed by the real name for anyything that gets trucated.

...
LOts_Of_GoBBILyyy_Gouc_Th4t_Is_M463_FrOm  ==>> This_Long_Symbol_Name_That_Dosnt_Actual_Fit_But_Can_Actually_Be_Read_And_Understood
...