On Sat, 2008-07-05 at 21:05 -0400, Mathieu Bouchard wrote:
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).
sorry, if i now seem to be nitpicking, but this is actually what i mean by 'core classes': the classes, that cover the initial focus of the library, in the case of gridflow the classes, that do deal with grids.
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.
i don't think, that something hardcoded as [range 8 9 10] in [#camera]/[pd camera] justifies the use an extra external, if three [moses] objects cover exaxtly the same.
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.
this is perfectly correct. however, i was inprecise by proposing to implement [range] with pure internals as abs. i rather meant: is it really necessary to have the exact functionality of [range]? cannot the same be achieved by having some [moses]es here and there? why adding a new class, if it not really extends the functionality of the language pd? but yeah, i agree: implementing the very same [range] as abstraction in pd as abs would be a pain and yet no possible without using externals.
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?
different languages provide different ways to deal with issues. i personally never felt the urgent need for a [range], although i so sometimes quite complex patches. i might be wrong, but i haven't seen a case yet, where [range] would be the only option to solve a certain problem.
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.
yes, you're right: there is no point in making an exact implementation of [range] as abstraction. but should there be any at all? i know, that you hate repetitioins in code and i agree with you, but in this case i am more in favor of repeating [moses]es instead of introducing another class, that doesn't really cover new possibilities. in this particular case, i also prefer [moses], because it does not crash, while [range] crashes pd, when sending it a list instead of a float message. from a developers perspective: why bother with making new code work, that introduces new problems and needs special attention, if pretty much the same could be achieved with a bit more effort in the user domain?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de