[PD-dev] bind abstraction-canvas to full classname

[Hans-Christoph Steiner]

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