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

[Kirk McDonald]

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.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org