[PD] declare [was: Re: Idiomatic Pd]

[Roman Haefeli]

On Thu, 2008-07-31 at 04:24 -0400, Matt Barber wrote:
> >> i question, if someone is seriously voting for the 'relative to parent'
> >> approach, since it is full of troubles:
> >
> > I think, I do. (if seriously is another question...)
> > to me an abstraction is like an include function (like for example in php).
> > let's say I create an abstraction that plays soundfiles and the filename
> > can be given as an argument or messages, then I want to write
> > [mysfplayer sounds/1.wav]. in this case, I want the file be relative to
> > the "parent" patch, because the parent patch will be in my project
> > folder, but the abstraction will be somewhere in an abstraction directory.
> 
> 
> Right -- is an abstraction like an include (macro?)?  Or is it more
> like a c file which is separately compiled and linked?  Or is it like
> a class definition which can have multiple instances, and might have a
> distinction between "public" and "private?"  I don't think any of
> these analogies is quite general enough to be satisfactory.  Your
> example is more complicated if your [mysfplayer] also lives in a
> different subdirectory -- is there a consistent (and/or idiot-proof)
> way of finding sounds/1.wav?
> 
> I think I prefer the 'relative to topmost' approach as well, if only
> because I tend to want to think of abstractions as objects.  The
> problem is, for most built-ins your path is declared at startup or in
> the parent patch, so things get a little itchier -- you need to be
> able to allow the path to be declared in the main patch, but you need
> to have an abstraction whose file might be located somewhere deep in
> that path inherit from the main patch the absolute paths of resources
> located in other directories, which is a little different problem than
> what happens to a declare inside an abstraction.  Depending on how
> things are defined, you could have soundfiles living in the same
> directory as the main patch which an abstraction living in a
> subdirectory can't find using the same name.
> 
> 
> For myself, I'd like to make some of the ideas I've seen in recent
> posts more explicit so I know I'm understanding the problems
> correctly.
> 
> So then let's say you have a complicated abstraction called
> [GUI_ambi_pan~].pd which you keep in ./GUI_ambi_pan/ (relative to the
> main patch), and you've defined it in such a way that stereo
> soundfiles which store, say, realtime azimuth and elevation
> coefficients, can be passed to it with $2.  For it to act
> transparently like an object you need it to inherit access to
> everything the patch it's instantiated in has access to pathwise, and
> with the same name, and again this is a deeper problem than what a
> [declare] inside an abstraction does.
> 
> On the other hand, let's say it also has a junkload of helper
> abstractions located in ./GUI_ambi_pan/helpers (similar, maybe, to a
> set of static functions in a C file or the private functions in a
> class definition), you might want a way to insulate the main patch
> from the abstraction's helpers -- or the flip side is you don't want
> the main patch to need to know about the abstraction's helpers in
> order to have them instantiated.  A "public/private" distinction for
> sets of abstractions would still have to be defined pathwise.
> 
> 
> 
> 
> If these are the problems, it leads me to believe that perhaps the
> -path syntax is too ambiguous to effect sufficient generality to be of
> any required specific use for relative paths inside of abstractions --
> it might help the problem to have different flags for different
> situations (at least the following):
> 
> 1) a switch for globally declaring that abstractions inherit the
> absolute paths using names defined relative to the parent (like
> declaring generally that abstractions behave like objects, using names
> you would use for built-ins).
> 
> 1.1) a switch for inside an abstraction declaring that it will search
> for files using names relative to its parent (this abstraction should
> behave like an object).
> 
> 
> 
> 2) a switch for inside an abstraction to export a path setting from a
> child to its parent, with the path defined relative to the parent
> (treats the abstraction more like a macro - you could use this e.g. to
> define a main patch's path using an abstraction, which might be useful
> for complex declarations in something like a sandbox environment --
> the same as just using the [declare -path ...] in the main patch, but
> as a ready-made set of things to include).
> 
> 2.1) a switch for inside an abstraction  to export an absolute path
> setting from a child to its parent, with the path defined relative to
> the child (I'm trying to think of a good use for this -- maybe if you
> wanted [soundfiler] and [my_groove_box~] to be able to access
> "sounds/johnson.wav" which lives in a subdirectory "sounds" of the
> directory my_groove_box~.pd lives in, and access it by the same name
> -- I don't think this is particularly useful and might be logically
> inconsistent).
> 
> 
> 3) a switch for inside an abstraction  to declare a "local" path
> relative to an abstraction's file (and by default unknown to the
> parent unless also declared there) -- probably overrides 1) just for
> this path?  In this case, if 2) or 2.1) is used for this path as well,
> you're using the abstraction as a kind of hybrid object/macro, where
> path is relative to the actual files -- there could be a global switch
> for this, too, or it could be the default.
> 
> 3.1) a switch for inside an abstraction to declare that such a "local"
> path is also "private" (or "static," etc.)... probably overrides 1)
> just for this path?  also throws an error when the same absolute path
> is declared by its parent.  Also throws an error when this same path
> is declared using a 2) or 2.1) switch.
> 
> 
> 4) a large set of error messages which are thrown when some path
> declaration is logically inconsistent, ambiguous, or when a resource
> or directory defined relatively is multiply defined somewhere in the
> search path -- and very well-defined default behaviors in the presence
> of an error (like with multiple [send~]'s with the same name).
> 
> 5) a "madcap hijinks" solution, which would be to allow search paths
> to be defined recursively -- [declare -path -r ./100_folders/] grabs
> everything in that directory including its subdirectories and their
> subdirectories.  This could be extremely useful in some situations,
> but breaky-breaky in a great deal of others.  Harder to make proper
> and useful checks, and the error messages thrown concise and
> meaningful.
> 
> So what happens if 1.1) and 3) are set for two different directories,
> but it finds a file with the same name in both of them (and it's not
> the same file)?
> 
> I guess the bottom line for me is that I'm okay with fuzzy or dumb
> [declare] statements breaking patches as long as proper errors are
> thrown and errant states are handled consistently -- I feel like the
> problem is just syntactical enough to be solved logically, and we
> should not throw up our hands at the possibility that someone could
> define paths wrong or ambiguously, or that it might be complicated to
> do it correctly in a way that allows sufficient generality and
> consistency at once.
> 
> 
> What I worry about is that solving anything like this might
> necessitate unwelcome changes to the current way paths are defined,
> which is why I would support adding flags to change the current
> (default) behavior, and enough flags to make this thing as expressive
> and powerful as needed.
> 
> Wow, I need to get to bed.  Sorry for the long post.

yo, i generally thinks as well, that it is a good idea to have a look at
other programming languages to see how they handle such issues. but at
the same time, we shall not forget, in what ways pd works differently.
the concept of expanding pathes relative to _somehting different_ than
file location is _new_ to pd and i still don't see why it should be
necessary.

'relative to file location' is old school pd style, easy to understand
and together with the concept of inheritance, it covers every use case i
can think of (which implies that i would try to adapt the way i code to
pd and not vice versa).

roman



	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de