[PD-dev] [range] from maxlib

[Mathieu Bouchard]

On Thu, 3 Jul 2008, Roman Haefeli wrote:

> ÿÿthe solution would be to give it a name, that clearly relates to
> gridflow. [gf.range] or whatsoever (similar to grid processing
> classnames starting with a '#').

Yes, I recently started using the "gf." prefix for some things, first some 
classes that are for quite internal use, and then in case of name 
conflicts, but I'd rather not put a prefix, really. Prefixes make the code 
heavier (among other things that make the code heavier)... compare:

   [jit.op @op +]
   [# +]

and note that they didn't write "jitter." -- and this is not because they 
were too lazy to write the full name.

> 'core classes' of gridflow (the ones starting with '#' )

The "#" does not stand for "core class". It stands for "grid". I always 
pronounce it "grid". I picked that symbol because it looks griddy (or 
gridful, gridsome).

Normally, a class whose name starts in "#" is a class that is made to 
handle grids. There are a few exceptions (or just one?) -- [#mouse] was an 
accident... it doesn't do any grids, it just postprocesses output of [#out 
window]. However, there are classes that take grids as inputs or outputs 
and don't have the prefix, namely the [cv.*] (OpenCV) classes... but 
that's another story that we could get into separately.

> and some additional classes, but it's the name, that distinguishes them. 
> this distinction made me believe, that there is something like a core 
> part and a peripheral part (whereas the peripheral part is not 
> necessarily necessary for the core part, that has the dedicated focus, 
> to work properly). this might be wrong and my own faulty personal 
> interpretation.

No, it turns out that the non-grid part is not there as purely optional 
add-ons... they are often required by abstractions that process grids. 
Stuff like [args] [listfind] [listread] [range] etc., are used by 
abstractions like [#camera] and whatever else.

> personally i think, that something like [range] shouldn't be part of an
> external at all, rather should it be simply an abstraction.

You can't make [range] without both variable number of arguments and 
[initbang] and dynamic creation of outlets, and by then, it's so 
complicated to have that done in Pd that I think it just can be done in C 
until Pd sucks less.

I mean, when something is more readable in C than in another language, 
it's usually a real bad sign for that other language... and it's not just 
about readability, it's about whether you can expect that the features 
that you need are there in Pd because if they aren't there you are 
screwed... where do you get [initbang] as an external?

So I don't have a clue why you say "it should be made as an abstraction" 
when it's not really doable at this point.

> however, the naming problem persists (and should be faced by adding some 
> library specific prefix, imo).

Yeah, that was the topic. I wouldn't necessarily say "should" though. I 
envision some other possibilities, such as overwriting the entry for 
[moses] and rename [range] to [moses] in all my patches.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec