hello,
i'm very concern about compatibility, but on the other hand :
- if you include a list_lenght in pd, lot's of people abstraction may have the
same name, but chances are that they all do the same, and that patch will not
be broken.
- one still can use it's abstraction with
myabstraction_folder/myabstraction_name, a shell script can easily fix that
- compatibility should not prevent a software improvement. i've got the
impression that in Max/MSP, most object could be simpler if compatibility with
30 years old version was abandoned.
so, if you introduce lot's of new objects, i'll be very happy, even if it break
my patch.
cheers
cyrille
Le 28/09/2012 17:23, Miller Puckette a écrit :
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
