[PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)

Frank Barknecht fbar at footils.org
Tue Sep 18 12:26:22 CEST 2007


Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

> This all sounds excellent, I think this is exactly what would work  
> well.  As for choosing standard namespace names, I think that we  
> should follow the lazy consensus rule, with required discussion,  
> i.e., standard lib names should not be automatically accepted unless  
> there is discussion.

I think there is need for discussion when it comes to the classes in
standard lib names, as I think, that the std-namespace(s) require(s) a
more elaborated style guide/specification. 

Two issues come to my mind immediatly. One is that the behaviour of
every of these std-objects needs to be discussed before they are
finally released into the wild to avoid future complications and
possibly incompatible changes and conflicting interfaces like we have
with [counter]. (Matju probably would wisely recommend to add tests as
well.)

Another issue would be the use of objects not in Pd core in such a
standard library. In my opinion and for reasons I mentioned several
times during the last days a Pd-std-library should work without
third-party externals (like the "purepd" or list-abs collections).

That's not because I don't like externals or would want to convince
everyone to never touch an external, it's just that a std-library for
a programming language should be self-contained. For example if you
install Python, a Python programmer can rely on the fact, that all the
modules delivered with the core-Python will definitely work. It's
still possible to use additional Python modules, but of course none of
the core-python modules depends on third-party modules like pyode etc.

Pd distributions like pd-extended or the packages included in the
various Linux-distributions may still opt to ship optimized
implementations of the std-library classes that use externals. I've
already mentioned as an example two versions of [list-drip]: one using
no externals as in list-abs and one just wrapping [zexy/drip].
Pd-extended could include the [list-drip] with [zexy/drip] as default,
users of e.g. PDa would maybe use the list-abs version. However as a
guideline I believe, that every std-class should have a purepd
implementation, otherwise it should not be included in that namespace.

As a side note I may add that finding solutions to some tricky
problems under the additional restriction to only use builtin objects
is a very satisfying experience. It makes you feel like a Master Of
The Universe(tm) ;-)

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__




More information about the Pd-list mailing list