This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16536 - Redundant statement
Summary: Redundant statement
Status: RESOLVED INVALID
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-27 13:52 UTC by Marcos Caceres
Modified: 2012-03-31 00:20 UTC (History)
2 users (show)

See Also:


Attachments

Description Marcos Caceres 2012-03-27 13:52:20 UTC
At :
http://dev.w3.org/2006/webapi/WebIDL/#es-boolean

I think the following is redundant:
"The IDL boolean value true is converted to the ECMAScript true value and the IDL boolean value false is converted to the ECMAScript false value."

The algorithm's steps already do that above, so you don't need this text (at least not here).
Comment 1 Marcos Caceres 2012-03-27 13:54:19 UTC
This is what it looks like implemented:

function toBoolean(V){
		//Let x be the result of computing ToBoolean(V).
		var x = ECMAScript.ToBoolean(V); 
		
		//Return the IDL boolean value that is the one that represents the same truth value as the ECMAScript Boolean value x.
		return x; 
		
		//The IDL boolean value true is converted to the ECMAScript true value and the IDL boolean value false is converted to the ECMAScript false value.		
}

So you can see that the last sentence just dangles there :)  Another idea would be to move it above the steps, so it sets up what is about to be implemented.
Comment 2 Cameron McCormack 2012-03-27 23:58:03 UTC
I don't think the algorithm does that.  The section here describes two things; the first, the algorithm, is how to convert JS values to IDL values of type boolean.  The second (which you quote) is how to convert from IDL values of type boolean to JS values, i.e. the other way.
Comment 3 Marcos Caceres 2012-03-30 18:40:55 UTC
Ok, I see why now I am getting generally confused (over and over again). I think you need to make it super clear what is actually happening in this spec... well in the ECMAScript "binding" section at least (for us noobies that just rush into the interesting ECMAScript section). 

The assumption I was working under has been wrong: I thought the ECMAScript binding section was about passing values and type checking them... which it kinda is... but I was missing one crucial step: the conversion to the abstract/language-independent WebIDL types. 

So, it should be made clear at the start of the ECMAScript binding section that... with regards to what it means to "bind" (or whatever): 

ECMAScript goes in -> gets abstracted to the appropriate WebIDL type (or throws TypeError if fails)... some of these types resemble ECMAScript types (e.g., Date)... but they are NOT ECMAScript types... they just look like them for convenience (or really just to confuse Marcos!:)). 

ECMAScript gets requested -> Browser converts WebIDL canonical type to ECMAScript -> out comes ECMAScript value.  

Hopefully I've now understood it correctly (and I'll stop getting things ass-backwards!).
Comment 4 Cameron McCormack 2012-03-31 00:20:59 UTC
(In reply to comment #3)
> The assumption I was working under has been wrong: I thought the ECMAScript
> binding section was about passing values and type checking them... which it
> kinda is... but I was missing one crucial step: the conversion to the
> abstract/language-independent WebIDL types. 

Yeah, that's exactly right.

> So, it should be made clear at the start of the ECMAScript binding section
> that... with regards to what it means to "bind" (or whatever): 
> 
> ECMAScript goes in -> gets abstracted to the appropriate WebIDL type (or throws
> TypeError if fails)... some of these types resemble ECMAScript types (e.g.,
> Date)... but they are NOT ECMAScript types... they just look like them for
> convenience (or really just to confuse Marcos!:)). 

Yep!  I considered using another name than Date for exactly that reason, but Ian thought it would be less confusing for authors to see Date there given that it's actually going to be an ES Date object that gets returned.

> ECMAScript gets requested -> Browser converts WebIDL canonical type to
> ECMAScript -> out comes ECMAScript value.  
> 
> Hopefully I've now understood it correctly (and I'll stop getting things
> ass-backwards!).

I believe you have. :)