[PD-dev] replace spaces in list class names with hyphens

[Miller Puckette]

THere isn't a 1-to-1 correspondence between the string that invokes an
object and its class -- hence, "list" can give rise to several different
classes, but also, there are sometimes multiple classes in Pd that have
the same "class name", like "select".  The string was originally only
there to help in pringing out error messages, (i.e. human readable), not
as a way to disamiguate anything.

I think the only way to know everything relevant is to know the whole
argument list and parse it, ouch...

cheers
Miller

On Fri, Jul 15, 2011 at 09:46:38AM -0700, Jonathan Wilkes wrote:
> 
> 
> --- On Fri, 7/15/11, IOhannes m zmölnig <zmoelnig at iem.at> wrote:
> 
> > From: IOhannes m zmölnig <zmoelnig at iem.at>
> > Subject: Re: [PD-dev] replace spaces in list class names with hyphens
> > To: pd-dev at iem.at
> > Date: Friday, July 15, 2011, 10:18 AM
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
> > > I've got a working tooltip prototype going, and I just
> > noticed that all the list classes screw up things on the tcl
> > side, because with "list append" (for example) it suddenly
> > looks like there is one more arg to the proc.
> > > 
> > > Are there any other objects that have a space in the
> > creator name?  If not, could we just make it official
> > that creator names can't have spaces, and change all the
> > "list foo" creators objects to "list-foo"?
> > > 
> > > This would be transparent to the user*, since they can
> > still type "list foo" and list_new will instantiate the
> > right class.  (Although going forward I would suggest
> > using "list-foo" as it is the standard for all the listabs
> > abstractions.)
> > > 
> > 
> > while i was always opposed to using object names with
> > spaces [1], i
> > don't think that we should forbid it at all. i would rather
> > have the GUI
> > side have an idea of what is the object name and what are
> > the arguments
> > (e.g. "create {list split} {1}" rather than "text list
> > split 1") than to
> > add arbitrary limitations.
> > 
> > some externals use "proxy objects" for full-fledged
> > non-first inlets,
> > and those proxies tend to have "hard to type" names as
> > well. how do your
> > tooltips deal with those?
> 
> So if object "foo" has a 2nd inlet controlled by a proxy object "bar", which class is referred to by t_object *ob of glist_drawio in g_text.c: foo or bar?
> 
> > 
> > gfmasdr
> > IOhannes
> > 
> > [1]
> > https://sourceforge.net/tracker/index.php?func=detail&aid=1544083&group_id=55736&atid=478072
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > 
> > iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
> > EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
> > =XO7J
> > -----END PGP SIGNATURE-----
> > 
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> > 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev