----- Original Message ----- > From: Martin Peach <martin.pe...@sympatico.ca> > To: Mathieu Bouchard <ma...@artengine.ca> > Cc: Jonathan Wilkes <jancs...@yahoo.com>; "pd-list@iem.at" <pd-list@iem.at>; > IOhannes m zmoelnig <zmoel...@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 > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list