[PD-dev] stripping down Pd-extended's default libs

[Hans-Christoph Steiner]

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  
> import.
>
> 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.  
> Maybe.
>
> 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?

.hc



----------------------------------------------------------------------------

Using ReBirth is like trying to play an 808 with a long stick.    - 
David Zicarelli