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

[Hans-Christoph Steiner]

On Sep 18, 2007, at 8:23 AM, IOhannes m zmoelnig wrote:

> Frank Barknecht wrote:
>> Hallo,
>>
>>
>> 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).
>>
>
> as far as i have understood it, the standard library wants to  
> duplicate
> externals: e.g. an object that allows interfacing with the serial port
> would be a copy of iem/comport that is named hardware/comport (or  
> whatever).
> thus it would not rely on "3rd party" externals, but on stdlib
> "internal" libraries. (with duplicate code and everything that follows
> from it)

They key difference would be that each stdlib would have a  
standardized interface, and each objectclass would conform to that  
interface.  For example, there could be an 'io' standard lib.   
Everything in that lib would respond to [open(, [close(, etc. in the  
same way, the first inlet would behave similarly, and the first  
outlet would be the data in the form of lists, and the second outlet  
would be status info in the form of lists.

So no, I don't think we should just copy over existing code without  
change.  Instead, we should use existing code when it's useful, but  
focus on having a clean and consistent interface for each library.

Then the old "author's name" libraries, like iem, zexy, ggee, etc.  
would remain in place for backwards compatibility.

.hc

>
>
> fma.dsr
> IOhannes
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



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

There is no way to peace, peace is the way.       -A.J. Muste