[PD] pd extended development
IOhannes m zmoelnig
zmoelnig at iem.at
Thu Apr 17 09:48:55 CEST 2008
Roman Haefeli wrote:
> On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote:
> how important is the portability between pd-extended and
> pd-vanilla/externals considered? any solution, that involves the
> [mylib/myclass] scheme creates patches, that are broken on a pd
> installation with multiclass externals.
at the beginning of this discussion (probably 2002 or so; i have no
idea) i posted a diff for Pd that would allow this: using
[mylib/myclass] after loading the multiclass-library "mylib" containing
the class "myclass".
the patch never got accepted (iirc, the arguing was that nameclashes
have to be solved on a social level rather than on a technical one)
> i think it is not up to me to ask such questions, but wouldn't it be
> generally better, if the multiple-class-per-external format would be
> simply dropped? this would also have the nice side effect, that noone
> would ever use aliasses anymore, which currently (and in the future?)
> aren't fully supported.
i think "generally better" would be to drop external support entirely
from Pd; this would reduce nameclashes a lot; i don't know how to solve
nameclashes of abstractions (without dropping abstraction support), but
one idea would be to just not distribute any collections (like
Pd-extended) anymore, and make the problem a _private_ one.
but i think we all agree that this is not going to happen.
anyhow, feel free to make Gem a single object per file library :-)
More information about the Pd-list