imho, if you're implementing a standard method, it's appropriate to throw if you know you are ignoring part of their request. e.g. if they pass the second argument and you don't use it for anything, throw an error.
— Thomas Aylott – SubtleGradient – MooTools – Cloudera — On Thu, Feb 17, 2011 at 1:43 AM, Jan Kassens <[email protected]> wrote: > As already pointed out, these aliases are not 100% compatible, because > they don't include the second argument for stringify and parse. > > I don't know if its worth adding this functionality, but I don't think > it's a good idea to pretend the standard compatible methods are there, > if they aren't. > > On Thu, Feb 17, 2011 at 10:34 AM, Peter Hewat <[email protected]> wrote: >> If you use another none Mootools aware script like Socket.IO-client >> for example, it requires parse and stringify. Socket.IO-client >> inculdes json.js in it's package. But in my case, I use Mootools so >> including json.js is redundant. If Mootools had these aliases (cf. >> Arian's code snippet) directly in it's core, you could remove json.js >> and it would work out of the box (hence my "simplify integration" >> comment). Adding json.js separably or manually adding this >> compatibility layer goes against Mootools philosophy (light is right, >> elegant cross-browser, etc.) >> >> Cheers, >> Peter >> >> On Thu, Feb 17, 2011 at 00:51, Christoph Pojer >> <[email protected]> wrote: >>> I don't want to question you but why is it important to you to "call >>> standard method names" if you are using a library anyway? I don't see the >>> point in doing this. JSON.encode and JSON.decode is perfectly fine. >>> Otherwise, do what arian proposed or load JSON2.js in your scripts :) >> >
