perhaps one solution is a set of objects (well documented) that
allows datatypes to easily be transmuted in ways that are clear and
easy to use for their new incarnation. Not that my vote counts, but
having clear separation between datatypes and how objects behave is a
boon. It makes for quick identifying of patching problems and for
logical separation of components.
On Jan 3, 2007, at 4:23 PM, Cyrille.Damez@laposte.net wrote:
Le Samedi 30 Décembre 2006 23:27, Mathieu Bouchard a écrit :
But how does the type of those cords represent anything else than limitations of the implementation?
Why should all the limitations of the implementation be hidden ?
Be it under the guise of unexplainable behavior or inefficient
patches, the Law of Leaky Abstractions will bite those who venture too far along
the road of "We have to hide this because the user really don't want to know."How does the choice of considering those things as distinct types, and the choice to not auto-convert
between types, constitute wise design decisions, beyond just being things
that we have to accept as fact in the context of Pd?Would
[bang( | [dac]
produce any sound if pd was automagically converting types ?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
v a d e //
www.vade.info abstrakt.vade.info