[L2Ork-dev] commit message clarification

[Jonathan Wilkes]

Hello,I just noticed this:
commit 5e18b837acd440ac4751c90c0c0b1e4a71623a2e
Author: Ivica Ico Bukvic <ico at vt.edu>
Date:   Thu Jul 18 16:41:53 2013 -0400

    fixed regression in select due to 37c0cf150e42e0277a0496cb73d48a114c64f0e7 commit which made it behave inconsistently thus making it impossible for floats to be treated as symbols (in cases where first argument was a symbol). Also introduced similar fix to the route object, thus allowing for second inlet to receive either float or symbol

***
What is the regression that this was meant to fix?  Basing the object's "mode" off of the type 
of the first argument as this commit does will _not_ allow floats to be treated as symbols as the 
commit message suggests.
If the implication is that you want this to work:[42(|[makefilename %d]|[select blah 42]
Then the implication is wrong, because you don't get a match that way under any version of 
[select] for any version of Pd.  Instead you get a match for the "42" slot on this:
[symbol(|[select blah 42]
That is, _any_ numeric argument will match an incoming empty symbol because that's what 
the SETSYMBOL macro does when you feed it a floatarg.
I'd like to revert back to my "mixed" mode algorithm so that the "42" slot matches on this:
[42(|[select blah 42]
and the "blah" slot matches on this:
[symbol blah(|[select 42 blah]
Mixing arg types isn't very common, but this is the only sane behavior I can think of (and it 
shouldn't have broken any patches in all the time [select] behaved this way in Pd-l2ork).
-Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20170326/e6ba9b4c/attachment.html>