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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
