[PD] moocow string2any

[Alexandre Torres Porres]

Em qua., 23 de dez. de 2020 às 18:10, Roman Haefeli <reduzent at gmail.com>
escreveu:

> Just for the sake of pduino, I wouldn't bother.


Ok, yeah, but it would be only because of the backwards compatibility issue
reported here by itself. And it bothers me cause I fear there's this image
of me where people can think "Alex will break backwards compatibility to
favor max compatibility" and that is not true :) Keeping backwards
compatibility is a thing for us and I've said it many times and even put it
in cyclone's readme. If there's an issue, if something broke - and that can
happen unintentionally - please report. As I explained, this was considered
a bug and was an unintentional breakage. I missed the fact that it was
documented in prepend's old documentation and that was a mistake. Once you
document it, you have to keep it or at least mention you changed it.

And checking purr data's cyclone/prepend, it's even more confusing. It's an
abstraction (for some reason) and that just keeps the second inlet with or
without arguments, even though its documentation says it's there only if
there's no argument.

Well, I'm thinking that the best way to clear up this mess now is to just
add and keep the second inlet for all cases and put a note this second
inlet in Append and prepend is not compatible to Max. It'd be easier to
document it also and it's a less stupid design. By the way, there are other
objects in cyclone that do have the same remark of some inconsistencies
regarding max compatibility, and even, although rarely, added
functionality. I'm openly not a fan of that, but I don't care enough to
make a case for it, so I kept it and documented it. I'm just saying this
cause, again, I don't want people reinforcing the idea cyclone is now
deliberately and mercilessly breaking stuff ;)

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20201223/1148e160/attachment-0001.html>