On Mon, 11 Jul 2011, Martin Peach wrote:
OK, but the object is responsible for knowing where it is, not Pd. If
the string is generated on-the-fly or stored elsewhere the object will
have allocated the memory for it.
Well, if pd has a default assist-method, externals might need a way to
give info to that assist-method so that it can do its own work. That would
be in t_class and in t_inlet.
In theory, tooltip strings could be stored in something at the
class-level instead of the object-level, just like methods called at the
object-level refer to a method-table stored at the class-level.
That is indeed what happens: a shared library has a section for strings (or
"data"). Unless it is generating them on-the-fly, each instance of the class
will refer to the same location in memory for its strings.
I mean exactly what I write, something at the class-level, not something
at the executable-level. That's because I'm thinking about a default
assist-method.
If there is no assist method, then Pd would use a default string from
its own class, depending on what types were registered to that
inlet/outlet at creation time.
There are several different purposes for the assist-method. Naming inlets
is one. Listing methods of an inlet is another. There are others. We have
to decide which such features we want to support, and then we will be able
to figure out what we need to add in t_class.
_______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
