On Mon, Dec 7, 2015 at 9:14 PM, Alexandre Torres Porres porres@gmail.com wrote:
Great & Awesome, Thanks!
But please allow me to make a suggestion and start a discussion.
[snip]
I'm fine in having some flexibility and not having the exact same functionality as in max, we could have other functionalities/features, so having two outlets could be meeting halfway - I just tend to criticize this need to maintain features and behaviours that emerged from mistakes and then adding other stuff around it and making it more complicating than just fixing it.
Anyway, those are my thoughts on it, anybody else?
In my view backward compatibility should be taken very serious in the case of any Pd class. I find it really annoying when classes change their behavior for anything other than a very compelling reason. Here's why: among the people who use Pd patches that we distribute, not everyone is so much aware of details discussed on Pd list, and then they don't know why a patch breaks.
You wouldn't believe how long a broken patch stays around. I've found the broken version of my patch SliceJockey on many people's computers, even months or years after I had uploaded a fixed version.
Hence my opinion: don't break backward compatibility unless you really must, like when a class produces incorrect mathematical results.
Katja