On Mon, 10 Dec 2007, Hans-Christoph Steiner wrote:
It is useful to represent the pieces in Pd space, so you can understand what's going on. That's one reason why I advocate having the core object represent the connection to the database rather than a query. Otherwise, it's starts to become more like Max/MSP's mega-objects (coll, zl, etc) that are really like mini-applications than programming.
I don't see your point. [zl] acts more like a namespace prefix than an actual class, so, it's really not much less modular than what it could be: most of the time it wouldn't make much of a difference to split it in smaller classes except splitting the help patch into tiny bits with more header and footer than actual content.
[coll] needs it like that because the data sits within [coll], it's not "functional" like [zl] is. Pd's arrays are likewise, but with less methods.
Neither [zl] nor [coll] seems to me like they have anything to do with the way to handle multiple connections. [coll] would be relevant if it offered a way to share the same collection across several [coll] objects.
I don't know what's a "mini-application" nor how it's supposed to always differ from what a class is.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada