Talk:Io.js: Difference between revisions

From MozillaZine Knowledge Base
Jump to navigationJump to search
No edit summary
Line 31: Line 31:


:: I don't think the changelog should be in the reusable js file itself. We can create a changelog section/subpage though. [[User:Asqueella|asqueella]]
:: I don't think the changelog should be in the reusable js file itself. We can create a changelog section/subpage though. [[User:Asqueella|asqueella]]
::: OK, but please include authors and contributors in the js file. --[[User:grimholtz|grimholtz]] 15:13 10 Mar 2005 (EST).


regarding returning false, I meant, change
regarding returning false, I meant, change
Line 47: Line 50:
return false;
return false;
</pre>
</pre>
: Sounds good! --[[User:grimholtz|grimholtz]] 15:14 10 Mar 2005 (EST).
Also I think returning <code>false</code> on failure isn't smart, <code>null</code> would be better.
Also I think returning <code>false</code> on failure isn't smart, <code>null</code> would be better.
[[User:Asqueella|asqueella]]
[[User:Asqueella|asqueella]]
: hm, why? I like minimizing the number of types that can be returned because it simplifies code which uses the class --[[User:grimholtz|grimholtz]] 15:15 10 Mar 2005 (EST).

Revision as of 20:16, 10 March 2005

asqueella's suggestions

I'd like to get point-by-point agree/disagree answer below from interested parties (grimholtz?), add long answers as subsections.

  • rename top-level ids -> FileIO2, DirIO2 to avoid conflicts with older code.
  • change Components.classes[this.dirservCID].createInstance(this.propsIID) -> getService (it is a service).
  • uncomment this ((?) I don't really see why that's commented): // data += uniConv.Finish();
  • remove DirIO.join/DirIO.split. File IO article has example for converting native path to URI and vice versa. I don't know how join/split can be used also, and this is not very clean XP code (hard-coding '\' for windows only doesn't seem smart).
  • rewrite FileIO.path()
  • move return false statements out of catch blocks
  • add dump() statements instead of // foobar!
  • personal: I would like the *CID/*IID members to be removed. I like the idea of creating wrappers for getService/createInstance, see below. This makes code much more readable IMO.
{
  createInstance: function(aCID, aIID) {
    return Components.classes["@mozilla.org/"+aCID]
          .createInstance(Components.interfaces[aIID]);
    },

  getService: function(aCID, aIID) {
    return Components.classes["@mozilla.org/"+aCID]
          .getService(Components.interfaces[aIID]);
  }
}
  • replace tab symbols with two-spaces. It is too wide for my 1024x768 screen now.
  • move examples from code to a separate section, add a link to io.js to the code.

me thinks about creating his own thin wrapper (like this for prefs) for file io...

They're all great ideas, in my opinion, except "move return false statements out of catch blocks." I want to know when the operation has failed (but not through an exception). Also, don't forget to increment the version counter from 0.1 to 0.2, as well as placing your name in the header comments. In fact, it might be a good idea to have a version history section in the header. Up to you. I have a few other suggestions that I'll type here tonight (code fixes and enhancements).
--grimholtz 13:54, 10 Mar 2005 (EST).
I don't think the changelog should be in the reusable js file itself. We can create a changelog section/subpage though. asqueella


OK, but please include authors and contributors in the js file. --grimholtz 15:13 10 Mar 2005 (EST).

regarding returning false, I meant, change

try {
  return "useful value"
}
catch(e) {
  return false;
}

to

try {
  return "useful value"
} catch(e) {}
return false;
Sounds good! --grimholtz 15:14 10 Mar 2005 (EST).

Also I think returning false on failure isn't smart, null would be better. asqueella


hm, why? I like minimizing the number of types that can be returned because it simplifies code which uses the class --grimholtz 15:15 10 Mar 2005 (EST).