Opened 12 years ago
Closed 12 years ago
#8952 closed task (fixed)
dojo.get/setObject unit tests
Reported by: | dante | Owned by: | anonymous |
---|---|---|---|
Priority: | high | Milestone: | 1.3 |
Component: | Core | Version: | 1.3.0b3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
There don't appear to be any. Someone pointed out to me a possible issue with getObject/setObject and I am unaware of any history behind it. eg:
var foo = { a:1 }; dojo.setObject("foo.a.b.c", 42); // should create foo.a.b.c = 42
It cannot create the b or c member because a is an int.
Also getObject fails under the same conditions:
dojo.getObject("foo.a.b.c.d.e.f.g.h", true); // should create ...
throws with "invalid in operand" while doing a "x in obj" at a
small unit test attached for setObject/getObject showing the failures. Unsure if they are intended or if we need more sanity checking in _getProp
Attachments (1)
Change History (5)
Changed 12 years ago by
Attachment: | setobject.patch added |
---|
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
I agree, it should fail or the behavior should be undefined. We don't need special code to convert a from an int to an object. As a rule of thumb in dojo we don't deal with error cases like this as it bloats the code.
comment:3 Changed 12 years ago by
Milestone: | tbd → 1.3 |
---|
agreed, just checking.
set/getObject is defined in _loader. my patch has these as a separate test. should I move them into _base/_loader/ tests or leave as-is (sans the intentionally failing tests?)
might at well do it before 1.3, right?
comment:4 Changed 12 years ago by
Component: | General → Core |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Type: | defect → task |
My first thought is that it should fail: if a is an int, trying to create a "b" property on the int should fail, since it fails in plain javascript. Trying to do:
var a = 1; a.foo = "hello"; alert(a.foo);
does not return "hello" (at least in Firefox and Safari). Since the methods are get/setObject, it seems reasonable to assume you are dealing with a mutable object chain.
It would be good to get the other unit tests in the tree though.