[PD-dev] future of [declare]

Hans-Christoph Steiner hans at eds.org
Fri Nov 7 20:12:00 CET 2008


What's wrong with having a declare with a local scope?  To have  
functional namespaces that encourage encapsulation, there needs to be  
at minimum two options: a global space and a completely local space.   
Then other levels could be added as desired. Currently, there is a  
global and a middle level, but no completely local.

That means that an abstraction could break depending on which parent  
patch it is used in.

.hc

On Nov 5, 2008, at 3:22 PM, Miller Puckette wrote:

> Followup:  it looks like currently, "declaring" a path inside an
> abstraction adds the declaration, buggily, to the whole line of parent
> patches.  one result of this is that, if you have a bunch of copies of
> an abstraction "declaring" a path, it actually gets searched over and
> over again every time a file is opened.  So I really need to fix  
> this...
> meantime, if you're putting "declares" in an abstraction, you might
> be making load times grow very high.
>
> I still suggest never putting declares insige abstractions, since  
> nobody has
> yet proposed a situation in which it's a good idea, and now it  
> appears to
> be very bad for performance.
>
> cheers
> Miller
>
> On Wed, Nov 05, 2008 at 12:06:00AM +0100, Roman Haefeli wrote:
>> hi all
>>
>> i made some tests with the new [declare] in 0.42.0test5. here the
>> results:
>>
>> -lib and -stdlib:
>> those expand the global namespace. when having [declare -stdlib
>> extra/zexy] somewhere, all zexy classes are available for any  
>> patches.
>>
>> -path and -stdpath:
>> they expand the namespace of the parent patch and all its (the  
>> parents)
>> children patches, children's children inclusive. to be more clear: a
>> [declare] in abstraction [foo] expands the namespace of abstraction
>> [bar], when both are instantiated in the same patch. also the parent
>> patch's namespace is expanded, but not the parent's of the parent.
>> other patches with no relationship are not affected at all by - 
>> path and
>> -stdpath.
>>
>> this behaviour differs quite significantly from the  
>> implementations of
>> declare in previous pd versions. also, unlike announced, it is _not_
>> disabled within abstractions. personally, i think, that is the best
>> [declare] implementation that we ever had. i think, it covers many of
>> the use cases one can think of, also because it affects the parent
>> patch. because all of that, i really hope, that the  declare's
>> 'philosophy' won't change too much in the future. out of curiosity  
>> and
>> out of the need of a reliable behaviour: what are the future plans  
>> for
>> [declare]? will it basically stay as it is (which i personally hope)?
>>
>> roman
>>
>>
>>
>>
>> 	
>> 		
>> ___________________________________________________________
>> Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo!  
>> Mail: http://mail.yahoo.de
>>
>>
>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev



------------------------------------------------------------------------ 
----

There is no way to peace, peace is the way.       -A.J. Muste






More information about the Pd-dev mailing list