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