 |
|
| .NET DotNet Forum Index » JScript .NET Forum » HELP: Strict JavaScript Syntax Checker Verifier |
|
Page 1 of 1 |
|
| Author |
Message |
| Dhruba Bandopadhyay |
 Posted: Fri May 11, 2007 5:24 am |
|
|
|
Guest
|
Two quick questions:
1. I really love Mozilla Firefox's javascript.options.strict mode (type
about:config in addressbar). However it still doesn't pick up on certain
things such as making it compulsory to have semi-colon as a statement
terminator. I have hundreds of organically grown JavaScript files that are
millions lines long. They are not written by me but by former employees and
I've been handed the job of debugging & fixing their code. Does anyone know
of a good Very strict JavaScript syntax verifier checker? What is the best
JavaScript IDE out there?
2. What happens if I keep on writing:
var control = new Control();
var control = new Control();
var control = new Control();
500 times? Will this cause a memory leak? Or will the previous object be
deleted since the reference is lost? Or is it handled differently in IE &
FF? |
|
|
| Back to top |
|
|
|
| Igor Tandetnik |
| Posted: Fri May 11, 2007 7:06 am |
|
|
|
Guest
|
"Dhruba Bandopadhyay" <dhruba.bandopadhyay@hotmail.com> wrote in
message news:OZVrUa7kHHA.3472@TK2MSFTNGP04.phx.gbl
Quote: 2. What happens if I keep on writing:
var control = new Control();
var control = new Control();
var control = new Control();
500 times? Will this cause a memory leak?
JavaScript is garbage collected. Eventually all these objects will be
destroyed, when GC gets around to them.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925 |
|
|
| Back to top |
|
|
|
| Dave Anderson |
| Posted: Sat May 12, 2007 2:41 pm |
|
|
|
Guest
|
"Dhruba Bandopadhyay" wrote:
Quote: 1. I really love Mozilla Firefox's javascript.options.strict mode
(type about:config in addressbar). However it still doesn't pick
up on certain things such as making it compulsory to have
semi-colon as a statement terminator.
ECMA-262v3 explicitly allows the omission of semicolons as statement
terminators. In fact, there is a whole section (7.9) devoted to automatic
insertion of them. What does it mean to "pick up on" something that is not
forbidden by the specification?
--
Dave Anderson
Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. |
|
|
| Back to top |
|
|
|
| Randy Webb |
| Posted: Sat May 12, 2007 5:13 pm |
|
|
|
Guest
|
Dhruba Bandopadhyay said the following on 5/11/2007 6:24 AM:
Quote: Two quick questions:
1. I really love Mozilla Firefox's javascript.options.strict mode (type
about:config in addressbar). However it still doesn't pick up on certain
things such as making it compulsory to have semi-colon as a statement
terminator.
That is a personal preference as there is nothing that says having a
semicolon as a statement terminator is mandatory. The closest thing to
it is if two statements are on the same line. But, JSLint will point out
things like missing;
<URL: http://www.jslint.com/lint.html>
I have hundreds of organically grown JavaScript files that are
Quote: millions lines long. They are not written by me but by former employees and
I've been handed the job of debugging & fixing their code. Does anyone know
of a good Very strict JavaScript syntax verifier checker? What is the best
JavaScript IDE out there?
2. What happens if I keep on writing:
var control = new Control();
var control = new Control();
var control = new Control();
500 times?
Your fingers will get tired before you get to 500.
Quote: Will this cause a memory leak?
No. Unless something in new Control points to control, or some other
circular reference, but even then it would only be 1 leak, not 500.
Quote: Or will the previous object be deleted since the reference is lost?
The first isn't deleted, it is overwritten by the second and so on. When
it finishes, there will be one control variable, the other 499 would get
overwritten.
Quote: Or is it handled differently in IE & FF?
I doubt it is handled differently.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ |
|
|
| Back to top |
|
|
|
| Igor Tandetnik |
| Posted: Sat May 12, 2007 11:48 pm |
|
|
|
Guest
|
"Randy Webb" <HikksNotAtHome@aol.com> wrote in message
news:UvadnWU3Ermbodvb4p2dnA@giganews.com
Quote: Will this cause a memory leak?
No. Unless something in new Control points to control, or some other
circular reference, but even then it would only be 1 leak, not 500.
All JS implementations I know of use mark-and-sweep garbage collection
algorithm or similar. They can happily collect data structures involving
cycles.
Quote: Or will the previous object be deleted since the reference is lost?
The first isn't deleted, it is overwritten by the second and so on.
While theoretically possible, this is highly unlikely in practice.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925 |
|
|
| Back to top |
|
|
|
| Randy Webb |
| Posted: Sun May 13, 2007 11:14 am |
|
|
|
Guest
|
Igor Tandetnik said the following on 5/13/2007 12:48 AM:
Quote: "Randy Webb" <HikksNotAtHome@aol.com> wrote in message
news:UvadnWU3Ermbodvb4p2dnA@giganews.com
Will this cause a memory leak?
No. Unless something in new Control points to control, or some other
circular reference, but even then it would only be 1 leak, not 500.
All JS implementations I know of use mark-and-sweep garbage collection
algorithm or similar. They can happily collect data structures involving
cycles.
Is that why there are no memory (circular) leaks created in IE when
using closures in some cases? Closures are exactly what I was referring
to and they don't get GC'ed in IE.
<URL: http://jibbering.com/faq/faq_notes/closures.html>
Quote: Or will the previous object be deleted since the reference is lost?
The first isn't deleted, it is overwritten by the second and so on.
While theoretically possible, this is highly unlikely in practice.
I don't believe that. Are you saying that there would be 500 variables
created/deleted in the example given? Or, does it simply reassign the
variables value 500 times? I say the second.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ |
|
|
| Back to top |
|
|
|
| Igor Tandetnik |
| Posted: Sun May 13, 2007 11:43 am |
|
|
|
Guest
|
"Randy Webb" <HikksNotAtHome@aol.com> wrote in message
news:Ad-dnULfscUVqdrb4p2dnA@giganews.com
The problem occurs when you have a closure, that holds a reference to a
DOM element, being used as an event handler for the same element (a
common pattern which has to be consciously avoided). A closure is a
JavaScript object managed by a mark-and-sweep GC. But a DOM element is a
COM object (in FireFox, an XPCOM object) whose lifetime is managed by
reference count. Since the COM object is outside of JavaScript world,
the GC cannot break this cycle.
Quote: Or will the previous object be deleted since the reference is lost?
The first isn't deleted, it is overwritten by the second and so on.
While theoretically possible, this is highly unlikely in practice.
I don't believe that. Are you saying that there would be 500 variables
created/deleted in the example given?
Depending on memory pressure, there may be multiple instances of Control
object created - indeed, up to 500. At some point, GC will kick in,
realize that all these instances are unreferenced, and destroy them all
at once.
Quote: Or, does it simply reassign the
variables value 500 times?
It will reassing the variable every time new assignment is performed. At
this point, the object the variable was referring to previously becomes
unreferenced, and fair game for garbage collection. But GC does not
destroy it right away.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925 |
|
|
| Back to top |
|
|
|
| Anthony Jones |
| Posted: Tue May 15, 2007 3:07 am |
|
|
|
Guest
|
"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:OQyYi3XlHHA.5084@TK2MSFTNGP03.phx.gbl...
Quote: "Randy Webb" <HikksNotAtHome@aol.com> wrote in message
news:Ad-dnULfscUVqdrb4p2dnA@giganews.com
Is that why there are no memory (circular) leaks created in IE when
using closures in some cases? Closures are exactly what I was
referring to and they don't get GC'ed in IE.
URL: http://jibbering.com/faq/faq_notes/closures.html
The problem occurs when you have a closure, that holds a reference to a
DOM element, being used as an event handler for the same element (a
common pattern which has to be consciously avoided). A closure is a
JavaScript object managed by a mark-and-sweep GC. But a DOM element is a
COM object (in FireFox, an XPCOM object) whose lifetime is managed by
reference count. Since the COM object is outside of JavaScript world,
the GC cannot break this cycle.
XPCOM? what's that? As I understood it DOM elements in FF are subject to
the same GC as Javascript objects hence unlike IE such a closure would not
result in a leak. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Thu Mar 18, 2010 7:35 pm
|
|