[Pdmtl] Style guide contributions
matju at artengine.ca
Fri Aug 22 11:32:32 EDT 2008
On Wed, 13 Aug 2008, Luke Iannini wrote:
> On Wed, Aug 13, 2008 at 5:48 PM, Mathieu Bouchard <matju at artengine.ca> wrote:
>> And then, giving $0 as an argument to an abstraction, is more like passing
>> your "self" as an argument to a "new", which, frankly, even in Python, could
>> be in any argument position, for any reason whatsoever. You could say that
>> it's preferable to put it early in the list, but there are many reasons it
>> could be elsewhere.
> Yea, I'm already convinced this was not a useful entry (just as a
> note, the "convention" portion referred to the fact that using the
> name "self" is a convention, you can name it "hamburger" if you want).
> I left it out of the "primordial style guide".
Well, I would prefer if it were called "hamburger" because "self" is
usually reserved for something different, namely the id of the receiving
object, not the id of any other object. Typically I call it "parent" or
"owner" or "callback" or such, depending on the type of relationship that
the two communicating objects will enjoy with each other.
> Yip, I'm certainly aware of this - the only goal I have is to set out a
> guide for those uninterested in inventing their own arbitrary
> conventions when just starting the language, so that some day in the
> future we have a useful and meaningful consistency (and, for those who
> think that's useful, to use).
I believe that Pd is too far into being used in many tortuous ways to
compensate for its lack of builtins, and into having everybody use their
own conventions... it will be very difficult to make it better. I mean
even if everybody started to use it tomorrow, there is a very large amount
of patches still in use and that will be reread and modified in the
future. People will not want to go back and modify existing patches.
People are ok enough with older stuff, so that they will not want to spend
time making them follow conventions, but it doesn't stop there. Any
modification to a patch is an occasion to make mistakes that will be hard
to notice because testing is tiresome and stuff. Some things are trivial
but some others are not. And then, old patches (especially abstractions)
have that influence on their surroundings, such that they will depreciate
the value of the new conventions because there is less consistency.
I believe that conventions tend to just feel like a bigger burden on the
job of making a patch and will not be perceived much for its advantages
even though it has advantages... (at least when you don't have to deal
much with anything that does not follow the conventions). It will be
thought of as One Thing Too Much To Think About when struggling for just
making the damn patch work.
> But, that is why I invite the advice of experienced Pd-users, since I
> think the conventions they've developed for themselves probably have
> good reasons.
I think that this is the case, but there are a lot of reasons why reasons
could in practice not be worth enough to implement those conventions as
> (and, please understand the term "ratification" as a joke given the
> nature of the Pd community)
I couldn't have known.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
More information about the Pdmtl