[PD] constants
Jonathan Wilkes
jancsika at yahoo.com
Thu Feb 16 20:53:19 CET 2012
----- Original Message -----
> From: Martin Peach <martin.peach at sympatico.ca>
> To: Mathieu Bouchard <matju at artengine.ca>
> Cc: Jonathan Wilkes <jancsika at yahoo.com>; "pd-list at iem.at" <pd-list at iem.at>; IOhannes m zmoelnig <zmoelnig at iem.at>
> Sent: Thursday, February 16, 2012 1:58 PM
> Subject: Re: [PD] constants
>
> On 2012-02-16 13:39, Mathieu Bouchard wrote:
>> Le 2012-02-15 à 13:11:00, Jonathan Wilkes a écrit :
>>
>>> Instead of time units, let's take the incoming single-selector
> "pi"
>>> and replace it with the float value of pi for any object that
> doesn't
>>> have a "pi" method or an "anything" method (but
> does have a float
>>> method). Furthermore, if a class defines a float argument but the
>>> argument provided isn't a float, then check first if what it
> received
>>> was A_SYMBOL 'pi' and if so replace with the float value of pi.
> Is
>>> what I wrote above possible to do without causing huge problems to
>>> performance or creating ambiguities?
>>
>> Compared to any code that checks whether something is A_FLOAT or not,
>> and branches accordingly, it makes absolutely no speed difference for
>> the case of A_FLOAT.
>>
>> And for the other case... the difference is that if you rely on A_SYMBOL
>> from being a type completely separate from A_FLOAT, for any reason, then
>> you're toasted. It's actually the same issue as the auto-convert
>> discussion from a while ago in which the symbol \123 would be regarded
>> as float 123 if you look at it this way, or as symbol \123 if you look
>> at it this way.
>>
But, for example, [route float pi] would still work the same because [route] has an
anything method defined and takes A_GIMME. So the problem would be limited
to users who need to rely on objects that don't have a method for anythings or,
specifically, don't have a method for "pi", or take float arguments. And by 'rely'
I mean they _need_ the object to give them an error in order for the patch to work
correctly, so that would be typos and runtime errors when you're sending one of
a subset of anythings to a float processing object or signal object.
-Jonathan
>
> That's why I think it's better to insert filter objects in front of just
> the appropriate objects, to prevent unintended conversions and not waste time
> checking to see if something might be convertible for no reason. IMHO pdlua is
> really good for symbol parsing, as it doesn't use the symbol table, and the
> script can be edited without needing to compile it, and it's just easier to
> manipulate strings in lua.
>
> Martin
>
More information about the Pd-list
mailing list