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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev