[PD-dev] bind abstraction-canvas to full classname
Hans-Christoph Steiner
hans at eds.org
Fri Jan 13 18:28:33 CET 2006
On Jan 13, 2006, at 4:17 AM, IOhannes m zmoelnig wrote:
> IOhannes m zmoelnig wrote:
>> but probably there is no way around.
>
>
> so i have re-submitted a patch to the patch-tracker.
> the new version now appends ".pd" to the receiver-name (using the
> pd-function addfileextent() which i just stumbled across and which
> seems to do what i need)
>
> so now [foo/bar] will bind to "pd-foo/bar.pd" (and for compatibility
> to "pd-bar.pd".
I am glad the .pd issue worked out easily.
I just thought of one thing. The "pd-bar.pd" compatibility binding for
[foo/bar] might not be the best thing to have. If you had [foo/bar]
and [bar], you would not be able to insure that you are independently
sending messages to [bar] with the symbol "pd-bar.pd" since both
[foo/bar] and [bar] would listen to pd-bar.pd.
I vote for clean implementation over backwards compatibility. (it is
still pd 0.* 8-)
.hc
>
> currently ".pd" is always suffixed (regardless of the actual
> file-extension). probably this could be done in a cleaner (more
> complicated) way, that respects the actual file-extension.
>
> so this should fix most concerns.
>
> the new patch is called "bind2classname.pd.diff" and i deleted the old
> one (which, btw, contained leftovers like m_class.c~...)
>
> mfg.adsr.
> IOhannes
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
________________________________________________________________________
____
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity."
-John Gilmore
More information about the Pd-dev
mailing list