----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at" pd-list@iem.at; IOhannes m zmoelnig zmoelnig@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