[PD-dev] from t_symbol to t_class

IOhannes zmölnig zmoelnig at iem.at
Sun Jan 13 11:57:36 CET 2013


On 01/12/2013 11:56 PM, Jonathan Wilkes wrote:
>>>   a t_class *s_class?  Would that affect performance?
>>
>> it would break binary compatibility.
>>
>> there's no good reason to add hash-like lookups to t_symbol (your only
>> reason is convenience).
>
> and avoiding code duplication.

i think that breaking binary compatibility is more important than code 
duplication, but ...


>>>
>>>   Then searching for an existing class would be easy-- just do
>>>   a gensym and check if its s_class exists.
>>>
>>
>> but checking whether a class exists, is as simple as calling zgetfn on
>> pd_objectmaker.
>> i think this is _quite_ easy.
>
> Well yes.  I meant searching for a class and _returning_ a class pointer.

...which only means that the current interface (using zgetfn with 
pd_objectmaker) is inadequate to your problem.


>
> So without adding/revising code inside class_new, is creating an instance
> the only way to get access to the class attributes?
>


unfortunately yes.

but adding/revising code inside class_new would retain 100% binary 
compatibility, whereas adding members to public structures is a 100% 
guarantee to break binary compatibiliy.


i think it is one of Pd's greater weaknesses, that so many data 
structures are exposed (rather than opaque).
if we had more accessor-functions, there would be less need to worry 
about binary compatibiliy.

fgamsdr
IOhannes



More information about the Pd-dev mailing list