Well, I'm persuadable on this front. I'm concerned with unduly hogging the object namespace - in general, every time I add an object name I potentially introduce incompatiblities with someone's abstraction that might have the same name. And there are 50 or so new classes (!) to provide. I don't even have a list yet (no pun intended)
cheers M On Fri, Sep 28, 2012 at 10:01:40AM -0400, Hans-Christoph Steiner wrote: > On 09/28/2012 04:00 AM, IOhannes m zmölnig wrote: > > On 09/28/2012 02:01 AM, Miller Puckette wrote: > >> Hmm... I agree there's bad confusion between array and table in Pd > >> nomenclature. I've tried to use "table" for a specifically floating-point > >> array, and "array" for the more general thing, but I think I've been > >> less than consistent (case in point, the "array" menu which creates what > >> I would call a "table". > >> > >> One idea might be to use the name [tab] instead of [array], as in > >> [tab size] - then [tabwrite] could get a synonym, [tab write], etc. > >> > > i'm quite with hans here: what exactly do we gain from having an object > > [tab write], instead of [tabwrite]? > > and i totally fail to see how [tab size] is superior to [tabsize]. > > > > in terms of remembering the names, they see quite on par; > > it is made clear that those objects belong to the same family regardless > > of whether the prefix is "tab" "tab " or "tab_", as long as there is a > > common short prefix; > > in terms of typing there is one more character to type; > > and from the implementation side, it needlessly compilates the > > object-lookup mechanism, as can be seen in the current implementation of > > the "list" family of objects (where the objectcreator is made aware of > > an object named "list\ size", but this object is practically never > > requested from the objectmaker, and instead the constructor function of > > "list" has to re-implement the dispatching. > > > > it's not that "foo bar" is bad by itself; i just don't see that it is > > anywhere better than what we already have. > And to hammer on this point some more, this subcommand syntax > complicates the implementation, as IOhannes points out, and complicates > the syntax. Its very nice to be able to say "Pd syntax is like > sentences where the first word is the command and the rest of the words > are data for that command." For all the newbies that I have taught from > all sorts of realms, from 10 year olds to practicing architects, this is > something that has really quickly clicked with basically everyone. In > my intro teaching, I avoid [list] for exactly this reason, because I'd > have to explain the exception to this simple "first word is the command" > rule, and some people are always confused by it. > > And from an advanced users point of view, the simpler the rules of the > syntax are, the brain space is taken up managing all of the exceptions > to nice, simple rules. And that means less brain space for far more > interesting things. > > .hc > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
