[PD-dev] [range] from maxlib
Roman Haefeli
reduzierer at yahoo.de
Mon Jul 7 16:28:33 CEST 2008
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
More information about the Pd-dev
mailing list