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

IOhannes m zmoelnig zmoelnig at iem.at
Tue Sep 18 15:43:50 CEST 2007


Georg Holzmann wrote:
> Hallo!
> 
>> 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)
> 
> As far as I undestood it the code of e.g. comport would go in this 
> standard lib (e.g. to hardware/comport) but should not duplicate the 
> code - instead the iem/comport code should be obsolete and now 
> maintained in hardware/comport.

that is obviously the idea of the stdlib maintainers.

nevertheless, it assumes that the auther of a certain object would 
happily give up "their" object and either maintain a stdlibized version 
or withdraw from maintaining the object alltogether (and someone else 
maintains the stdlibized version)

i guess, the 1st option is the one we would want to see happen.

nevertheless i have some doubts: often, objects can not simply be 
"moved" into the stdlib, but they should follow some "standard" (hence 
the name!) design principles (of the interface).
but changing the interface of an object is a heavy modification, which 
needs a lot of social competence)
(i am pretty sure that there are lots of ideas how to make objects in 
zexy more "consistent" with other objects, however i have spend a lot of 
time in designing the API (at least for some of them :-))

Pd-externals are usually FLOSS.
this gives us the technical permission to duplicate the code. it is not 
necessarily a social permission.

mfgad.sr
IOhannes




More information about the Pd-list mailing list