[PD] array size (was Re: arraysize)

[Hans-Christoph Steiner]

On 09/28/2012 11:43 AM, Claude Heiland-Allen wrote:
> On 28/09/12 16:23, Miller Puckette wrote:
>> Well, I'm persuadable on this front.  I'm concerned with unduly hogging
>> the object namespace - in general, every time I add an object name I
>> potentially introduce incompatiblities with someone's abstraction that
>> might have the same name.  And there are 50 or so new classes (!) to
>> provide.
>> I don't even have a list yet (no pun intended)
>
> Perhaps it would be better to refactor the object / abstraction /
> binary / loading / namespace mechanism first, something along the
> lines of an old discussion I had with HCS:
>
> http://claudiusmaximus.goto10.org/cm/2010-07-16_pure-data_libraries_conversation.html
>
>
> Once that is fixed to something less baroque/crufty then it should be
> easier for everyone to go nuts and have their own namespaces without
> clobbering or hogging anything, and make patches more portable between
> Pd variants.
>
> I have no time to work on this for the forseeable future, but it's
> something that needs doing sooner rather than later...
>

I totally agree with this.  I think the easiest place to start would be
to rework the load order, so that instead of going by file type, it goes
by directory.  Right now, the load order first looks for .pd_linux files
in every dir in the path, then looks for .pd files in every dir in the
path.

Instead it should start by searching or .pd_linux and .pd in the patch's
own dir, then .pd_linux and .pd the canvas-local path, then  .pd_linux
and .pd  in the global path, then  .pd_linux and .pd  in the built-in path.

Currently, if you don't know that there is a 'foo.pd_linux' installed in
your path, and your project folder includes 'foo.pd', your project will
always load 'foo.pd_linux'.

.hc