[PD] [*] vs [*~]

[vade]

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 at 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 at 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070103/e66e66e5/attachment.htm>