Re: [PD-dev] from t_symbol to t_class

[IOhannes zmölnig]

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

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] from t_symbol to t_class

[Jonathan Wilkes]

- Original Message -

 From: IOhannes zmölnig zmoel...@iem.at
 To: pd-dev@iem.at
 Cc: 
 Sent: Sunday, January 13, 2013 5:57 AM
 Subject: Re: [PD-dev] from t_symbol to t_class
 
 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 ...

Nevertheless its important to avoid code duplication, for obvious reasons.

 
 
 
    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.

Yes.

 
 
 
  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.

And if I just put the struct inside m_class.c but not in m_pd.h is that enough
to keep it from being exposed?

Another questions-- inside class_new when I add a class/symbol pair to
the list (I suppose by calling a function to add an entry to the list), I need 
to
walk the current list to see if that symbol has already
been added and overwrite the old class pointer with the new one, right?  And
if so, won't this searching add to the patch load time?

-Jonathan

 
 
 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
 
 ___
 Pd-dev mailing list
 Pd-dev@iem.at
 http://lists.puredata.info/listinfo/pd-dev
 

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev