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

Mathieu Bouchard matju at artengine.ca
Thu Sep 20 22:02:26 CEST 2007


On Tue, 18 Sep 2007, Hans-Christoph Steiner wrote:

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

That's also called an "interface", a "protocol", a "contract", or an 
"abstract class".

For example, if I have [comport], [tcpsocket] and [file] classes, all 
three of which implement the io protocol, then any of those three can be 
called "an io object", or "an object of the io class", and each of those 
three's helpfiles can refer to the io protocol help file instead of 
copy-pasting each other, and then you have help files about classes that 
are not implementations and which you can't instantiate because they only 
exist documentation-wise, and that's alright. That's a direction that I 
advocate for PDDP.

This concept is independent from namespaces. It has to, to some extent, 
because often a class will implement multiple protocols. Even in the io 
department, you can split the io interface into "readable", "writable", 
"seekable", etc.; then it's better to have the namespace go with a 
category of classes that are related by their protocol relationships, but 
don't necessarily all implement a same single protocol.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada


More information about the Pd-list mailing list