From: kangax on
David Mark wrote:
> On Nov 19, 2:40 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 19, 12:29 am, kangax <kan...(a)gmail.com> wrote:
>>>> David Mark wrote:
>>>>> The "base" parts.
>>>> [...]
>>>>> throw Error('Namespace "' + name + '" already declared.');
>>>>> Bad form. Throw new Error.
>>>> Why? Isn't the result identical (as per 15.11.1)? Or are there
>>>> deviations in "real world"?
>>> Bad _form_. :)
>> How do you quantify "bad _form_"?
>>
>> new Error over Error doesn't seem to make the code any more readable,
>> doesn't observably affect performance or outcome, AFAIK.
>
> This is one where I agree with Crockford. You always use - new - with
> Error and never with String, Number, etc. Imagine what String and
> Number objects would do to this thing's is* methods.

I don't see how using `new` with `Error` is anything but a personal
preference ;) To me, the version with `new` is just as good of a form as
the one without it, but yes, this is the least of evil in that library.

Regardless, this is something that should probably be done by a
minification tool like YUICompressor or Closure Compiler (that is, if
omission of `new` is an argument for using it to save on code size).

I've already filed few enhancements with Closure Compiler
(http://code.google.com/p/closure-compiler/issues/detail?id=36) and just
proposed `new Error` --> `Error` as well
(http://code.google.com/p/closure-compiler/issues/detail?id=36#c12).

[...]

--
kangax
From: David Mark on
On Nov 19, 4:36 pm, kangax <kan...(a)gmail.com> wrote:
> David Mark wrote:
> > On Nov 19, 2:40 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 19, 12:29 am, kangax <kan...(a)gmail.com> wrote:
> >>>> David Mark wrote:
> >>>>> The "base" parts.
> >>>> [...]
> >>>>>       throw Error('Namespace "' + name + '" already declared.');
> >>>>> Bad form.  Throw new Error.
> >>>> Why? Isn't the result identical (as per 15.11.1)? Or are there
> >>>> deviations in "real world"?
> >>> Bad _form_.  :)
> >> How do you quantify "bad _form_"?
>
> >> new Error over Error doesn't seem to make the code any more readable,
> >> doesn't observably affect performance or outcome, AFAIK.
>
> > This is one where I agree with Crockford.  You always use - new - with
> > Error and never with String, Number, etc.  Imagine what String and
> > Number objects would do to this thing's is* methods.
>
> I don't see how using `new` with `Error` is anything but a personal
> preference ;)

Form is personal preferences. There are lots of ways to do
everything. Best to stick to a subset. If I want to construct a new
object, I use the - new - operator, despite the fact that I could
leave it off for some types of objects.

> To me, the version with `new` is just as good of a form as
> the one without it, but yes, this is the least of evil in that library.

Technically it is every bit as good (and per the specs). But I don't
have to remember that.

>
> Regardless, this is something that should probably be done by a
> minification tool like YUICompressor or Closure Compiler (that is, if
> omission of `new` is an argument for using it to save on code size).

I really dislike this minification trend. If you don't test the
minified result (which can be a pain), you are relying on blind
faith. As we've seen that the Closure "compiler" can make a mockery
out of JS, I can't see putting such faith in it. On the contrary, I
see comments where people have "tested" it against YUI and declared
Closure the winner because it made _their_ script(s) smaller without
wrecking them (as far as they know).

>
> I've already filed few enhancements with Closure Compiler
> (http://code.google.com/p/closure-compiler/issues/detail?id=36) and just
> proposed `new Error` --> `Error` as well
> (http://code.google.com/p/closure-compiler/issues/detail?id=36#c12).
>

Why are you bothering with this shipwreck?
From: kangax on
David Mark wrote:
> On Nov 19, 4:36 pm, kangax <kan...(a)gmail.com> wrote:
[...]
>> Regardless, this is something that should probably be done by a
>> minification tool like YUICompressor or Closure Compiler (that is, if
>> omission of `new` is an argument for using it to save on code size).
>
> I really dislike this minification trend. If you don't test the
> minified result (which can be a pain), you are relying on blind

It should be trivial to check well tested code. If there are functional
tests (besides unit ones) � even better.

> faith. As we've seen that the Closure "compiler" can make a mockery
> out of JS, I can't see putting such faith in it. On the contrary, I
> see comments where people have "tested" it against YUI and declared
> Closure the winner because it made _their_ script(s) smaller without
> wrecking them (as far as they know).

Yeah, that's stupid. YUICompressor, on the other hand, does only safe
translations (which is why its compression is not on par with Closure
one). I've been using it all the time without any problems whatsoever.

In any case, it IS possible to munge code in a "safe" way, as long as
you know what you're doing. I'm sure Closure Compiler will get there one
day ;)

>
>> I've already filed few enhancements with Closure Compiler
>> (http://code.google.com/p/closure-compiler/issues/detail?id=36) and just
>> proposed `new Error` --> `Error` as well
>> (http://code.google.com/p/closure-compiler/issues/detail?id=36#c12).
>>
>
> Why are you bothering with this shipwreck?

I happen to enjoy language intricacies.

And why is it a shipwreck? They are doing a good job (with compiler, not
library, of course). If they make a safe compression tool, it would
benefit everyone.

--
kangax
From: David Mark on
On Nov 21, 12:20 am, kangax <kan...(a)gmail.com> wrote:
> David Mark wrote:
> > On Nov 19, 4:36 pm, kangax <kan...(a)gmail.com> wrote:
> [...]
> >> Regardless, this is something that should probably be done by a
> >> minification tool like YUICompressor or Closure Compiler (that is, if
> >> omission of `new` is an argument for using it to save on code size).
>
> > I really dislike this minification trend.  If you don't test the
> > minified result (which can be a pain), you are relying on blind
>
> It should be trivial to check well tested code. If there are functional
> tests (besides unit ones) — even better.

If you have a complete set of unit tests (hard to measure), you can
predict the success of the munged version. But any non-trivial app is
going to require a lot to prove that everything survived the munging.

>
> > faith.  As we've seen that the Closure "compiler" can make a mockery
> > out of JS, I can't see putting such faith in it.  On the contrary, I
> > see comments where people have "tested" it against YUI and declared
> > Closure the winner because it made _their_ script(s) smaller without
> > wrecking them (as far as they know).
>
> Yeah, that's stupid. YUICompressor, on the other hand, does only safe
> translations (which is why its compression is not on par with Closure
> one). I've been using it all the time without any problems whatsoever.

I've used it and never had a problem. When I use it now, I test the
munged version only.

>
> In any case, it IS possible to munge code in a "safe" way, as long as
> you know what you're doing. I'm sure Closure Compiler will get there one
> day ;)

Who knows?

>
>
>
> >> I've already filed few enhancements with Closure Compiler
> >> (http://code.google.com/p/closure-compiler/issues/detail?id=36) and just
> >> proposed `new Error` --> `Error` as well
> >> (http://code.google.com/p/closure-compiler/issues/detail?id=36#c12).
>
> > Why are you bothering with this shipwreck?
>
> I happen to enjoy language intricacies.
>
> And why is it a shipwreck? They are doing a good job (with compiler, not
> library, of course). If they make a safe compression tool, it would
> benefit everyone.

How are they doing a good job with the "compiler?" Okay, that one's
more of a train wreck. Sure it might work some day and maybe it will
make a tiny difference in some scripts. But it's the library is a
mockery and ISTM that there is coupling between the two (something
about the browser sniffing and filtering browser-specific script at
"compile" time).