Last Comment Bug 742195 - Implement the extended attributes for null and undefined handling on string arguments in Paris bindings
: Implement the extended attributes for null and undefined handling on string a...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: mozilla17
Assigned To: Peter Van der Beken [:peterv]
:
Mentors:
Depends on:
Blocks: ParisBindings 753517 784869
  Show dependency treegraph
 
Reported: 2012-04-03 21:57 PDT by Boris Zbarsky [:bz]
Modified: 2012-08-28 22:00 PDT (History)
3 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 (10.08 KB, patch)
2012-08-22 16:57 PDT, Peter Van der Beken [:peterv]
bzbarsky: review+
Details | Diff | Splinter Review
v1.1 (9.73 KB, patch)
2012-08-23 17:05 PDT, Peter Van der Beken [:peterv]
peterv: review+
Details | Diff | Splinter Review
v1.2 (9.93 KB, patch)
2012-08-23 17:42 PDT, Peter Van der Beken [:peterv]
peterv: review+
Details | Diff | Splinter Review

Description Boris Zbarsky [:bz] 2012-04-03 21:57:05 PDT
We'll need it sometime.
Comment 1 Peter Van der Beken [:peterv] 2012-08-22 16:57:57 PDT
Created attachment 654431 [details] [diff] [review]
v1
Comment 2 Boris Zbarsky [:bz] 2012-08-23 14:03:37 PDT
Comment on attachment 654431 [details] [diff] [review]
v1

The mapping from the python enum to the C++ enum is a bit weird because we depend on treatAs having the same ordering as the python enum.

What if we used just a dict mapping the WebIDL string values to our desired string values, and then just stored the WebIDL string value in the IDLArgument?  That would at least nix the ordering dependency.  If we wanted to really be cool, we could change our C++ string values to match the WebIDL ones (e.g. replace eStringify with eDefault or something).

In the WebIDL parser, I don't think we should raise an error on TreatUndefinedAs=Missing.  That's not a problem for the parser per se, and the codegen will already raise an error on it.

In the codegen, even if type.nullable() we need to examine treatUndefinedAs, no?  In particular, if the argument is "[TreatUndefinedAs=EmptyString] DOMString?" then passing undefined should produce an empty string.

r=me with those last two bits fixed and maybe some parser tests added.  A followup bug is fine for the string/enum stuff.
Comment 3 Peter Van der Beken [:peterv] 2012-08-23 17:05:25 PDT
Created attachment 654854 [details] [diff] [review]
v1.1
Comment 4 Peter Van der Beken [:peterv] 2012-08-23 17:42:21 PDT
Created attachment 654874 [details] [diff] [review]
v1.2
Comment 6 Ryan VanderMeulen [:RyanVM] 2012-08-24 20:04:43 PDT
https://hg.mozilla.org/mozilla-central/rev/d5f32f0e1c05

Note You need to log in before you can comment on or make changes to this bug.