Recently after a refesh of code from comm-central,
I noticed that running |make mozmill|
TB test suite using full DEBUG BUILD of TB produced the
following warning lines:

System JS : WARNING
file:///REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/components/steelApplication.js:783
- mutating the [[Prototype]] of an object will cause your code to run
very slowly; instead create the object with the correct initial
[[Prototype]] value using Object.create


I get the warning lines as often as TB binary is invoked (35 times).
I think it is an enhancement of JS system to print out the warning
like above.

Looking at the installed steelApplication.js under object directory, I
found the following line which is marked as "=>".

    //@line 63
"/REF-COMM-CENTRAL/comm-central/mail/steel/steelApplication.js"

=>  Application.prototype.__proto__ = extApplication.prototype;

    const NSGetFactory = XPCOMUtils.generateNSGetFactory([Application]);

I suspect that the code may not run very often (once each TB
invocation).
But is ignoring this issue safe and OK, or should we rewrite the code
(but in
what way)?

BTW, It is nice that JS interpreter (?) seems to have become
developer-friendly and produce something like the following which
helps to trace the execution of the program at the time of exception
very much:

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "[JavaScript Error: "null has no properties" {file:
"chrome://messenger/content/folderPane.js" line: 1796}]'[JavaScript
Error: "null has no properties" {file:
"chrome://messenger/content/folderPane.js" line: 1796}]' when calling
method: [nsIFolderListener::OnItemRemoved]"  nsresult: "0x80570021
(NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame ::
resource://mozmill/modules/frame.js ->
file:///REF-COMM-CENTRAL/comm-central/mail/test/mozmill/folder-pane/test-folder-names-in-recent-mode.js
:: test_folder_names_in_recent_view_mode :: line 67"  data: yes]
************************************************************

Considering that developers probably spend more than 2/3 or 3/4 of their
time debugging/testing code [I am not kidding],
such developer-friendly error output goes a long way to help the
developer community.

Very nice work!

I think such improvement for testing/debugging is much more important
than, say, making the speed of JS interpreter 5% or something. But
people's opinions probably vary. It all boils down to where to place
what priority. I tend to value developer's time very much. Making sure
to use developer's time efficiently is the only way to sustain long-term
development cycle.

TIA





_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to