[PD-dev] loaderHEX bug report

[IOhannes m zmoelnig]

Hans-Christoph Steiner wrote:
> 
> On Nov 22, 2005, at 11:39 AM, IOhannes m zmoelnig wrote:
> 
>> Hans-Christoph Steiner wrote:
>>
>>> What about alt_0x3c0x3c0x3c_setup()?  That would highlight that its an
>>
>>
>> but this really makes and object called [alt_0x3c0x3c0x3c] impossible!
> 
> 
> The setup function would then be alt_alt_0x3c0x3c0x3c_setup(), so it  
> would be possible.

the alternative setup-function of [<<<] is "alt_0x3c0x3c0x3c_setup()"
the primary setup function of [alt_0x3c0x3c0x3c] is 
"alt_0x3c0x3c0x3c_setup()" (the same!)
the secondary setup function of [alt_0x3c0x3c0x3c] is 
"alt_alt_0x3c0x3c0x3c_setup()"

> How about sys_load_lib_hex() and hex_blahblah_setup()

i like these names. however, sys_load_lib_alt() does not no anything 
about the encoding of the alternative classname (whether it is hex or 
some base62 or whatever)


after rethinking the setup-name, you are probably right.
the setup-functions are really only called within the given 
library-file. so pd will be able to call the correct setup function in 
the correct library. (i do this so seldomly...)
the only important thing is, that the file for [<<<] is NOT called 
alt_0x3c0x3c0x3c.dll but just 0x3c0x3c0x3c.dll


and finally (just one more rant ;-)) i still don't understand the real 
drawback of setup_XXX() vs hex_XXX_setup().
imo, this just makes unneccessary typing. in both cases you have to be 
aware that you are making a non-standard setup-function, and i tend to 
want to type less than necessary (otoh, i have typed quite a lot on this 
topic; most likely more than i ever will by using the hex_ prefix)


mfg.gadr
IOhannes