Talk:GM.getValue: Difference between revisions
No edit summary |
m Attempting to close out the discussion, since it appears to be "acceptable" to everyone for over 9 months. :) |
||
Line 60: | Line 60: | ||
I'll file a ticket and a patch shortly. | I'll file a ticket and a patch shortly. | ||
--[[User:Gingerhendrix|Gingerhendrix]] 09:29, 7 January 2008 (EST) | --[[User:Gingerhendrix|Gingerhendrix]] 09:29, 7 January 2008 (EST) | ||
Unless there is further discussion on this... I have included Gingerhendrix's paraphrased explanation in the usage section. Bullet 1 can eventually be removed. [[User:Marti|Marti]] |
Revision as of 09:01, 30 September 2008
- Ref: 0.7.20070607.0 Release on a.m.o prefmanager.js
- Line 49
return null;
- Ref: Current trunk as of 2007 01 03 prefmanager.js
- Line 52
return null;
- There is a difference between null and undefined.
null
is an object (e.g.alert(typeof(null));
)undefined
has no memory allocated (e.g.alert(typeof(undefined));
)
- If the desired behavior is to return undefined, it will need to be corrected in the trunk as well as a.m.o.
Try something along the lines of
// ==UserScript== // @name GetSetValueTest // @description Tests the behaviour of gm_getValue for a missing property // @include http://www.example.com/ // ==/UserScript== var val = GM_getValue("missingProperty"); var msg = "val: " + val + "\n" + "typeof(val): " + typeof(val) + "\n" + "val==undefined: " + (val==undefined) + "\n" + "val===undefined: " + (val===undefined) + "\n" + "val==null: " + (val==null) + "\n" + "val===null: " + (val===null) + "\n"; alert(msg)
I get:
val: undefined typeof(val): undefined val==undefined: true val===undefined: true val==null: true val===null: false
I believe (but haven't tested) that lines 36-38 returns defaultValue (i.e undefined) and lines 50 and 52 are never executed.
if (prefType == pref.PREF_INVALID) { return defaultValue; }
--Gingerhendrix 21:13, 6 January 2008 (EST)
LOL We're both correct here.:) In your test case it will return undefined because no default value was supplied... however in my test case here it will return null because I made sure that the value stored wasn't a string, int or boolean.
Do you think this is worth a trouble ticket for devjavu?
Marti
How do you reach this codepath - i.e. how do you make sure that the value stored wasn't a string, int or boolean? I'll file a ticket and a patch shortly. --Gingerhendrix 09:29, 7 January 2008 (EST)
Unless there is further discussion on this... I have included Gingerhendrix's paraphrased explanation in the usage section. Bullet 1 can eventually be removed. Marti