> MooTools' goal is not to get you writing standards-based JavaScript.
> It is to make JavaScript more pleasant and easy to write, read,
> maintain, and use.
+1
(Long post, sorry. Nothing particularly important, but I had the
time.)
I don't dream of a future in which I call setAttri
Garret, it's clear you're a little turned off by the coding philosophy of
MooTools. The JSON implementation isn't really that big of an issue, but the
broader philosophy of what MooTools does is in line with it. We don't
implement addEventListener for browsers that don't have it, choosing instead
a
> MooTools class system
> prevents you from using JavaScript instanceof.
Says who?
http://jsfiddle.net/rpflorence/MkqQQ/
On Feb 17, 2011, at 7:43 AM, Garret Wilson wrote:
> On Feb 17, 1:34 am, Peter Hewat wrote:
>> ... Adding json.js separably or manually adding this
>> compatibility layer g
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
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 T
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
If you really want to use JSON.stringify, just do:
if (!JSON.stringify) JSON.stringify = JSON.encode;
if (!JSON.parse) JSON.stringify = JSON.decode;
Furthermore I agree with Christoph.
On Wed, Feb 16, 2011 at 11:51 PM, Garret Wilson wrote:
> On Feb 16, 7:57 am, Christoph Pojer wrote:
>
> > JSO
Whether you like those function names or not, they have become the de facto
standard. I personally find those names pretty straight forwards but that is
beside the point. Other scripts that don't necessarily use Mootools but use
JSON use those names. It would be good if Mootools also added alias
ools-users@googlegroups.com
Subject: Re: [Moo] Re: Native JSON encoding and decoding.
Personally, I think Crockford should be shot for creating "stringify" and
"parse". It's "encode" and "decode" in other languages, and that's what I
would prefer to use i
Personally, I think Crockford should be shot for creating "stringify" and
"parse". It's "encode" and "decode" in other languages, and that's what I
would prefer to use in JavaScript too.
On Tue, Feb 15, 2011 at 9:14 PM, Garret Wilson wrote:
> On Feb 15, 2:22 pm, Christoph Pojer wrote:
> > or: f
or: fixed.
done.
The native JSON functions have additional arguments for a reviver
function. This arguments should probably be dropped by the MooTools
methods or implemented there. Currently, the additional argument is
only supported on some browsers.
On Tue, Feb 15, 2011 at 10:58 PM, Christoph Pojer
wrote:
> Hel
Hello,
https://github.com/mootools/mootools-core/compare/17cf2d029a...b43547b036
will be in 1.3.1
Pull request:
https://github.com/mootools/mootools-core/pull/59
On Tue, Feb 15, 2011 at 11:01 AM, Jan Kassens wrote:
> Hi Peter,
> MooTools had the JSON object before it was specified. This is the
> reason the method names are different and the implementation of the
> browser isn't used if pres
Hi Peter,
MooTools had the JSON object before it was specified. This is the
reason the method names are different and the implementation of the
browser isn't used if present. As Aaron said, I think someone added
the support but it must have been lost somewhere.
This shouldn't be that big of a deal
Hi Aaron,
What is the reasoning behind not using the browsers native JSON if
available?
Regards
That was simply an error. It was added ages ago but somehow got lost in a
merge or something. This is atypical. When we make changes to MooTools Core
and push it to trunk, it is not likely to disappear.
MooTools *is* actively maintained. The JSON implementation present in
MooTools 1.3 is full feat
18 matches
Mail list logo
