[PD-dev] the future of [declare] and canvas_savedeclarationsto()

[Hans-Christoph Steiner]

On May 20, 2008, at 8:54 AM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> I think this issue is pretty clear, and the languages that I know
>> would fall along the lines of "each patch/abstraction has its own
>> namespace" or in other words "#include only affects the one .c
>> file",  "import only affects the one .py file", etc.  So I agree with
>> Frank.  Global settings are global, and canvas-local settings are
>> local to the original file.
>
> I think, it's not yet "pretty clear" at all otherwise we wouldn't
> discuss this issue so often. Here are some random thoughts on the
> topic.
>
> The languages you mentioned have something like a scope, they know
> global and local variables. In Pd, everything is global and there is
> no local scope as far as I can see. Even $0 evaluates to a global
> value, that is easily accessed from the outside of an abstraction. So
> you cannot just take a concept from, say, Python and include it
> one-to-one in Pd - it has to be adapted. (Also Pd has more in common
> with LISP or Lua than with C or Python IMO, so we should look there
> first.)

I don't know Lisp or Lua, so I can't speak to that.  Please do give  
examples.  Basically, I think that every objectclass should have its  
own namespace.  That fits into the core idea of objectclasses being  
distinct, reusable modules of code.  If the parent patch affects an  
abstraction, that makes the objectclass dependant on the parent  
patch, which is not a good thing.


> Currently [declare] modifies global settings like path and loaded
> libraries, that you normally modify outside of a patch with
> .pdsettings/.pdrc or command line options. That's simple and beautiful
> at first, but has the ugly side effect of conflicting declares, that
> need to be resolved. Having the toplevel [declare] win over other
> declarations is simple as well, but not that beautiful anymore as it
> makes writing abstractions more error prone because they cannot rely
> anymore  on their own declarations being valid. So in the end I'd
> agree with you that we would (also?) need a way to modify settings in
> a non-global way. As far as I see it, we'd have two places for doing
> this: We could use a restricted scope for such declarations either
>
>  a) per abstraction i.e. in a region where $0 is equal.
>  b) per subpatch: [pd zexy-is-loaded-here]
>
> It could also be realised with messages sent to "pd-subname", but
> that's probably not a good idea because of execution order problems.
> Or is it?

[declare -std*] modifies the global namespace [declare] with -lib and  
-path modify the canvas-local namespace.  I think it should be like  
this:

- global namespace is global
- local namespace for each distinct canvas (parent patch and  
abstractions)

Tcl has namespaces that can be used across procedure/class, provided  
you import them into procedure/class.  I suppose Pd could have that  
too, so you could set dependencies across a whole project.  But I  
don't see this as being especially useful in Pd, and it would add  
complexity.

If I write an objectclass (aka abstraction), I only want to have to  
think about what libs that objectclass needs.  I don't want to think  
about how those libs related to other files in the project at that  
point.  Having the local namespace per objectclass/abstraction allows  
for this.

.hc

>
> Ciao
> -- 
>  Frank Barknecht                                     _  
> ______footils.org__
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev







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

"It is convenient to imagine a power beyond us because that means we  
don't have to examine our own lives.", from "The Idols of  
Environmentalism", by Curtis White