[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