> if someone built abstractions with the same name, is it likely that they
> have different behaviour?
Some of the signal objects would have to have a different behavior
because of how [inlet~] works. If [inlet~] could take an optional
float arg to output a constant sig (tough because it takes symbol args
as well, but not impossible), then you could have abstractions which
could take creation arguments *or* signals in all inlets in one
abstraction implementation. Otherwise [inlet~] promotes float
messages already, but it's very buggy in canvases that have an [inlet]
to the left of [inlet~](s). With the current tools it's hard to
implement some of them efficiently, too.
Other problems with abstractions would be something like "gate" -- you
need [initbang] for that one, which is not in vanilla (it's otherwise
very easy to make an abstraction out of) -- or [spigot] could become a
multi-outlet object whose only difference from [gate] is the (proper,
IMO) "right inlet controls" Pd style -- this is one of the "proper
behavior" problems that has come up recently; [pow~] was another, if
my memory isn't shot.
One slightly different tack would be instead of trying to bring
cyclone (etc.) into vanilla, to just ensure the existence of
standalone control and signal objects for all the functions and
operators in the expr suite -- that would be a decent start. It would
at least satisfy those who want a more complete set of mathematical
tools without needing to use expr; it seems that's where most of the
complaints have come of late.
Matt