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

[Hans-Christoph Steiner]

Besides [list], what are other exceptions to the rule of the class  
being all characters before the first space?  It might just be easier  
to code in an exception for [list].

.hc

On Jul 15, 2011, at 1:41 PM, Miller Puckette wrote:

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





----------------------------------------------------------------------------

"[T]he greatest purveyor of violence in the world today [is] my own  
government." - Martin Luther King, Jr.