[PD-dev] stripping down Pd-extended's default libs
hans at eds.org
Mon Feb 23 05:50:23 CET 2009
On Feb 22, 2009, at 9:09 PM, Mathieu Bouchard wrote:
> On Fri, 20 Feb 2009, Hans-Christoph Steiner wrote:
>> On Feb 18, 2009, at 2:57 PM, Mathieu Bouchard wrote:
>>> That said, I'm not very fond of declarations, but I don't think
>>> that it's an issue of programmers vs non-programmers, it's a
>>> matter of people who like to declare vs people who don't, and
>>> that's a quite different split. There are quite a lot of serious
>>> programming languages that avoid declarations as much as possible.
>> Can you give some examples of how other langauges handle this kind
>> of thing without delcarations?
> Not really...
> In Smalltalk you don't have declarations like this, because there
> are no namespaces, and because there are no files to load.
> In Ruby you load files, but they don't have to be tied with any
> classnames in particular. Loading a file can be considered a
> declaration if you wish, but it's an action. There are namespaces,
> but you import them by performing the action of adding a superclass
> to the class that you are in (even though all ruby docs deny that
> this constitutes multiple-inheritance... go figure!)
> In Tcl, there are namespaces, though many libraries don't use them.
> You have file-loading just like Ruby's, and you have packages
> implemented in terms of file-loading. Declarations are really
> actions in this language too. Namespaces exist, but were added after
> many years of existence of the language. (Not counting the other
> kind of namespace called "ensemble" and that has nothing to do with
> the newer feature called "namespace"). The import feature is
> probably similar to Python's, I don't know; it works as an action as
> well, of course.
> A big difficulty with namespaces in Pd is that the user doesn't
> control the loading order of objects, and objects aren't "run" in
> the way a program is, so [import] has to be very special. If Pd were
> more like one of the above systems, you'd be able to [loadbang] an
> [import] before the rest of the patch loads; but this is only one
> way of thinking about the correspondence between languages...
> depending on how we decide to map concepts across languages, we
> would get to different possible equivalences of features.
> Tcl and Ruby don't have a two-in-one load-and-import "declaration",
> whereas Python and Perl do. Some other languages may look like they
> have a load-and-import declaration, but instead have only an import
> declaration, and do all the loading automagically: for example, in
> Java, you can say java.util.Vector and it gets loaded, no need to
> About declarations in general and languages that avoid them, it's
> something that doesn't apply so well to namespaces as it does to
> other language features that don't apply to Pd.
> Something you could take from Java is that creating the objectbox
> [zexy/foo] would cause the loading of zexy.pd_linux if it is found.
> My main advice would still be to avoid having to use any
> declarations for things that ought to be internal classes in Pd but
> aren't. That's very subjective. For example, much of zexy and
> iemguts could go in that category, imho, and much of many other
> libraries as well.
Yes, import/declare ends up being a bit weird. Mostly, I think the
main issue is when someone adds an import midway thru a patch. Then
next time it loads, it could end up having different files loaded for
the stated objectclass names.
Perhaps then changing [import] should force the whole patch to
reload. That would be annoying since the patch would lose its state,
but I suppose the state could even be saved somehow.
Or perhaps there is an even better solution out there for something
like namespaces in a visual programming language. Any ideas?
Using ReBirth is like trying to play an 808 with a long stick. -
More information about the Pd-dev