[PD-dev] from t_symbol to t_class

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-01-13 18:50, Jonathan Wilkes wrote:
>> 
>> 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"?

yes, that shouldn't be a problem.
i was mainly concerned about your plans to extend the existing
t_symbol (but i might have misunderstood your suggestion).

> 
> 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?
> 

yes. obviously, all code that you add will eventually take some ime to
execute.
however, i wouldn't worry too much about that before it becomes
obvious that it takes too long...Pd already handles quite a number of
linked lists that are searched linearily. e.g. calling class_new()
already checks, whether the new class is already in the long list of
objectclasses registered with pd_objectmaker, and this is not the
reason why it takes long to load large patches.

otoh, it would of course be nice to abstract these hashtable-like
structures away, in something like std::map; this would make it easy
to switch to a different algorithm (eg. binary trees) once we find
that a linear search is the bottleneck.

fgasmdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlD0Bz0ACgkQkX2Xpv6ydvT0ggCg0h1nqbsPzsuKTUhxa+yd4Khk
9G4An1nt6vfPlQj3lMLf4+M0j9PJbk5F
=J5Ry
-----END PGP SIGNATURE-----