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, [EMAIL PROTECTED] 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
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
