On Mon, Dec 7, 2015 at 9:14 PM, Alexandre Torres Porres <[email protected]> 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
