Comments regarding pd-arraysize_0.1-1_amd64.changes

[Roman Haefeli]

On Sun, 2010-11-07 at 14:00 -0500, Hans-Christoph Steiner wrote:
> On Nov 5, 2010, at 7:01 PM, Roman Haefeli wrote:

> > I'm interested to hear other opinions on this.

> pd-arraysize is a special case, not an example of how to do things.  
> There are plenty of simple packages in Debian, like simple kernel  
> modules for a very specific device.  In general packaging a single  
> simple object not a good idea, IMHO, but this one has a long legacy.
> arraysize has many uses, and is still widely used by people in their  
> patches, I use it regularly.

Now while thinking more about this, I realized why I never felt the need
for [arraysize] or any other measure to know the size of an array in the
the few years of using Pd: It's known already at any time. I can't think
of a situation where the size of an array is unknown. Actually, it is
always known, either because the table was provided a size argument or
the size was changed by loading a (sound-)file (an action that also
returns the new size, if '-resize' was used). To me this object is
basically useless. Checking the existing abstractions and help-files
using [arraysize] showed that [arraysize]  is only used in cases where
the patch author missed to keep track of the current size. I
acknowledge, though, that patching can be sometimes a lot easier with
[arraysize] under certain circumstances.

>   It is also widely used in many Pd docs.   
> And many people prefer the simple syntax of typing "arraysize" vs  
> "expr size($s1)".

If you care about naming, then why don't you put [expr size("$s1")] into
an abstraction called [arraysize]? I don't think [arraysize] is more
useful simply because it has a better name.

>   Additionally, expr is GPL and arraysize is public  
> domain, so some people will use arraysize for that reason (i.e. a  
> proprietary app based on Pd like rjdj).

Good point.

I also checked how it is done in current releases of Pd-extended: There
[arraysize] was put into a folder called 'flatspace'. Would anything
speak against making a Debian package pd-flatspace out of all of those
externals and abstractions found in flatspace? To me it seems that this
folder is now used as a bin for an arbitrary and unrelated set of
externals and abstractions that are not part of another library or don't
fit well into another library. Why not keeping this structure also for
Debian packages? Then we would have a home for stuff like [arraysize].

Roman