[PD] pd extended development
Luke Iannini (pd)
lukexipd at gmail.com
Thu Apr 17 00:27:35 CEST 2008
Python's namespacing has these features that I haven't seen discussed yet:
There are three common ways to import:
"import list-abs", which just makes list-abs available for use, but
you still need to type "list-abs.list-map" (the Python equivalent of
[list-abs/list-map]). [1]
"from list-abs import list-map", makes it possible to just type "list-map".
And finally "from list-abs import *", makes it possible to type any of
the functions in list-abs without a prefix.
The 3rd option is widely discouraged, because it makes it very unclear
where a function comes from, or which one is in use.
I greatly appreciate this arrangement, and I think it would be wise to follow.
A 4th feature that reduces verbosity is the ability to write "import
list-abs as l". And of course once things actually work, [list-map]
could be renamed to just "map" to give [l/map], which I think is
great.
Cheers
Luke
On Wed, Apr 16, 2008 at 2:55 PM, Hans-Christoph Steiner <hans at eds.org> wrote:
>
>
> On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote:
> > Hallo,
> > marius schebella hat gesagt: // marius schebella wrote:
> >
> >> Frank Barknecht wrote:
> >>> Hallo,
> >>> marius schebella hat gesagt: // marius schebella wrote:
> >>>
> >>>> sorry, I still don't know exactly what you mean. I think it is
> >>>> the only
> >>>> solution to keep libraries in subfolders if we want to solve
> >>>> nameclashes. but even if in subfolders, they should be
> >>>> accessible as
> >>>> list-abs and not list-abs/list-abs.
> >>>
> >>> Huh? Nameclashes have nothing to do with subfolders per se. A
> >>> nameclash
> >>> is, when two objects have the same name registered in Pd but act
> >>> differently. Folders are a way to organize files in a filesystem
> >>> (harddisk).
> >>>
> >>>> the thing that I was complaining so loudly is that pd-extended
> >>>> ships all
> >>>> these libraries but does not add the paths.
> >>>
> >>> Yes, that's exactly what I mean: Many people would like every
> >>> objectclass to be global.
> >>
> >> but that is not a problem for pd-extended users (and I want to
> >> solve the
> >> pd-extended problems here), as long as you can overrule the global
> >> namespace with a local namespace.
> >
> > Not really: Say I use [urn] in Pd-extended. Which [urn] am I using?
> >
> > As pd-extended by popular demand (and for practical reasons) is
> > configured to allow access to one of the [urn]s out of the box, I
> > believe not many people are actually using the names [zexy/urn] or
> > [maxlib/urn] or [cyclone/urn]. But all of these behave differently.
> > So we have a hidden nameclash if you try to use a patch that assumes
> > [urn] to be the one from the library, pd-extended loads as the second
> > one. Now IIRC Hans' goal is to not load any library or set any path
> > out of the box, so that all names would have to be qualified with
> > directory prefixes or [declare]d. But when this behavious accidentally
> > came into effect because of the change in plist-location on OS-X,
> > people complained about missing objects and that their patches were
> > broken with the new pd-extended. Note that I don't want to rate if
> > they complained for a good reason, I just want to point to a problem.
> >
> >> pd-extended would provide a default object for every nameclash.
> >> If you have old patches that were using objects, that are not the
> >> default in pd-extended you would have to add a declare to your
> >> patch. or
> >> explicitely call them as mynondefaultlib/abs~.
> >
> > So you see: pd-extended selected a certain set of externals to be the
> > default set of available objectclasses in pd-extended. I don't know
> > how it was decided which libs should be these defaults, I don't even
> > know which ones are the defaults. Probably Hans just chose some
> > popular ones, which is a sensible thing to do.
> >
> > In the long run, this process should become a bit more organized and
> > it especially should not be handled along library/author borders. For
> > example, I think, zexy (rightfully) has a high loading priority,
> > because it's one of the oldest and most widely used library. But
> > Cyclone also deserves a high priority because it's generally
> > Max-compatible. OTOH zexy is older. What to do? If we only priorize
> > complete libraries, we're not able to make finely grained decisions
> > about single objects. Maybe zexy's [abs~] is better, while [urn] in
> > Cyclone is preferable.
> >
> > In the end we may be back at square one: a "flatspace" with the
> > selected best of the (un)pack objectclasses in a single directory. No
> > problems with path settings, all is fine again.
> >
> > Or what am I missing? ;)
>
> The flatspace model breaks down when you start adding libraries to Pd-
> extended. Then you can have nameclashes again. Say someone writes
> their own library with an [urn], then what happens? At best,
> confusion ensues.
>
> If we look at other programming languages, we can see that namespaces
> are a very common solution to this problem (C++, Tcl, python, Java,
> Smalltalk, etc). I see no reason why it wouldn't work for Pd as well.
>
> .hc
>
>
> ------------------------------------------------------------------------
> ----
>
> There is no way to peace, peace is the way. -A.J. Muste
>
>
>
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
More information about the Pd-list
mailing list