[Pdmtl] Style guide contributions

[Mathieu Bouchard]

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 
standards.

> (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