[PD-dev] overriding "internals"

[IOhannes m zmoelnig]

Hans-Christoph Steiner wrote:
> 
> On Nov 10, 2007, at 3:55 AM, IOhannes m zmoelnig wrote:
> 
>>
>> cyclone does something like this (it overrides already registered 
>> externals, which - at this point - are not different from internals)
>>
>> it is basically looking whether the class-name is already registered, 
>> and if so, overwrites the class-pointers.
>>
>> however, for this to work, you need first need to call a function in 
>> your overriding new library.
>> therefore you will probably need something like a "library" (instead 
>> of single, same-named externals)
> 
> I'd rather not use a special mechanism, especially if it is not already 
> widely used.

well you asked, i gave you an answer.
but then i probably have not read your original email as careful as i 
have should.

> 
>>> I was thinking of just breaking out the classes into their own 
>>> files,  then compiling things as a libdir.  This is pretty easy for 
>>> most of  the objects, but I haven't gotten into the DSP classes yet, 
>>> and I  expect things will be more complicated there.  And [list] too.
>>
>> funnily enough i have always been opposed when requesting that the 
>> [list] objects get _proper_ names.
> 
> Why?  For example, [list append] will happily append a symbol to a 
> float, so the "list" part doesn't seem so accurate.  Why not just [append]?

probably because of [append] already exists?


> 
> The libtkwidget.so would be included in the libdir to make it a simple 
> package.

so how do you convince the ldopen to look for the libtkwidget.so in your 
libdir instead of whatever is configured in /etc/ld.so.conf?

i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as 
"a simple package".

i would really be interested in a solution for this.


mf.asdr
IOhannes