[PD] array size (was Re: arraysize)

[Miller Puckette]

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