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

[Hans-Christoph Steiner]

On Sep 18, 2007, at 6:26 AM, Frank Barknecht wrote:

> 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) ;-)

We would not have Gem, PDP, PiDiP, hid, ann, pdogg, streaming, theora/ 
speex/mp3 externals, etc. if we did not allow externals to use non- 
core libraries.  Instead of arbitrary restrictions, we should make an  
environment where people can count on having the libraries they need  
in the same place on every machine.  This is a key thing about Java,  
Debian, etc. and this is the core purpose of Pd-extended.

I think it's a good idea to try to use the core functions over other  
libraries, but it would needlessly restrict possibilities of what  
people can do with Pd to limit which libraries can be used.

.hc




>
> Ciao
> -- 
>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



------------------------------------------------------------------------ 
----

I have the audacity to believe that peoples everywhere can have three  
meals a day for their bodies, education and culture for their minds,  
and dignity, equality and freedom for their spirits.      - Martin  
Luther King, Jr.