| 12:03 | <Ms2ger> | <!-- next section refers to previous section as "previous section" --> |
| 12:06 | <Velmont> | Glad we got that cleared. |
| 12:12 | <Ms2ger> | Feel like reviewing some tests? |
| 13:14 | <MikeSmith> | heycam|away: anything's possible |
| 20:07 | <Hixie> | heycam|away: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=20496 |
| 20:09 | <Stevef> | 35,730 home pages (from top 50,000 sites) gathered yesterday, in 1 large zip file get it from http://www.webdevdata.org |
| 20:21 | <Stevef> | me/ useful for revealing cowpaths and undermining arguments from authority |
| 20:22 | Stevef | useful for revealing cowpaths and undermining arguments from authority |
| 20:25 | <tantek> | SteveF - I prefer to think of evidence as outweighing (rather than undermining) arguments from authority. :) |
| 20:57 | <Stevef> | tantek: yeah right, I used 'refuting' here https://twitter.com/stevefaulkner/status/285489160985382914 which I think is more fitting |
| 21:00 | Stevef | thinks it would be great if a web company that has easy access to the sort of raw data that I have been collecting would make it available on a regular basis... |
| 21:02 | <tantek> | ooh a CG too. (clicks Join) |
| 21:52 | <annevk> | Hixie: if you want to treat Nan/Infinity different it seems you might need to do that in prose |
| 21:53 | <annevk> | Hixie: unless we're going to introduce Nan and Infinity as values somehow so you can do (NaN or double)... |
| 22:19 | <annevk> | Hixie: the video player thing, do you mean the way it seeks? It was annoying me to no end yesterday trying to find those bugs you referred to... |
| 22:35 | <Hixie> | annevk: that has to be prose, but my point is just that the return value is always "double", not "unrestricted double" which is what the setter value has to be |
| 22:35 | <Hixie> | annevk: yes, the way it seeks in particular |
| 22:36 | <annevk> | Hixie: if the setter is more generic, it doesn't really matter |
| 22:36 | <Hixie> | we could make all the attributes "any", too :-P |
| 22:36 | <annevk> | Hixie: for readonly attributes, that's basically true :) |
| 22:36 | <annevk> | (unless I'm missing something) |
| 22:50 | <annevk> | arv_: re es-discuss: does this mean the ArrayClass experiment has failed? |
| 22:50 | <annevk> | arv_: should we pursue something else instead? e.g. Hixie's toArray() suggestion? |
| 23:31 | <annevk> | heycam: maybe we should have getattribute {type} {name}; and setattribute {type} {name}; for cases where they behave different? although that still does not help with PutForwards I guess... |
| 23:31 | <heycam> | annevk, maybe, I guess I'm not that fussed about the syntax particularly |
| 23:32 | <heycam> | annevk, I see the feature as "the attribute actually has type X, but additional some values of other types are accepted when assigning and get converted to the appropriate value of type X, or handled in some other way" |
| 23:32 | <heycam> | not really sure why it should be that controversial |
| 23:33 | <annevk> | I think it's mostly smaug____ that considers it controversial |
| 23:34 | <annevk> | though for everything but PutForwards one can just loosen the type as the prose already determines what is returned |
| 23:34 | <smaug____> | annevk: bz and IIRC also sicking have been agains PutForwards |
| 23:34 | <smaug____> | against |
| 23:36 | <gsnedders> | annevk_: the ArrayClass experiment? |
| 23:37 | <annevk_> | heycam: btw https://mail.mozilla.org/pipermail/es-discuss/2012-December/027688.html (unclear per logs whether this got true) |
| 23:37 | <annevk_> | s/true/through/ |
| 23:37 | <heycam> | smaug____, I think asymmetric get/set types for attributes is dissimilar enough from PutForwards to consider it on its own merits |
| 23:38 | <heycam> | annevk_, oh interesting, will read |
| 23:38 | <smaug____> | I'm not sure I understand its merits |
| 23:38 | <heycam> | I think it just makes it clearer in the IDL that certain values will not be returned when getting the attribute |
| 23:38 | <heycam> | but it also gets around restrictions where we say e.g. sequences can't be the type of an attribute |
| 23:38 | <smaug____> | it feels a bit odd if setting an attribute needs to run ctor of something taking the value as param |
| 23:39 | <heycam> | you could have it be allowed to be assigned to the attribute, as long as you return something different when getting |
| 23:39 | <smaug____> | it is the creation-of-new-objects which is odd |
| 23:39 | <heycam> | I see |
| 23:40 | <heycam> | so you'd rather have the author do an explicit `new FileList(sequenceOfBlobs)`? |
| 23:40 | <annevk_> | values get converted all the time |
| 23:41 | <annevk_> | e.g. 1 -> "1" |
| 23:41 | <smaug____> | that is very different |
| 23:41 | <annevk_> | I don't see why |
| 23:41 | <heycam> | the restriction on sequence types for attributes is the only thing stopping writing `attribute (FileList? | sequence<blob>) files;` |
| 23:41 | <heycam> | and then having prose only ever return a value of type FileList |
| 23:42 | <smaug____> | annevk: you certainly aren't creating new objects that way |
| 23:42 | <smaug____> | is there any case when a new object is created automatically |
| 23:43 | <annevk> | I don't really see value in differentiating primitives and objects |
| 23:43 | <gsnedders> | smaug____: "foo".indexOf("a") creates an object, if that counts |
| 23:43 | <annevk> | you'd want the same kind of behavior to apply to both |
| 23:44 | <heycam> | I think anne's point of 1 -> "1" is that this is the more general issue -- assigning one value, and getting a different value back if you get the attribute later |
| 23:44 | <smaug____> | heycam: also, are there other use cases for this conversion? |
| 23:45 | <heycam> | Hixie pointed out https://www.w3.org/Bugs/Public/show_bug.cgi?id=20496 earlier as another case that could use it |
| 23:45 | <heycam> | so you want to have some particular processing of Infinity/NaN when assigning, but you never want to return those values |
| 23:45 | <heycam> | you could just have `unrestricted double` as the type and in prose never return non-finite values |
| 23:46 | <heycam> | but it might be easier to understand for readers of the spec if it is in the idl |
| 23:48 | <annevk> | gsnedders: the email is about that, yes, and about how maybe we should introduce something like Array, but readonly, to solve it |
| 23:52 | <heycam> | do we actually have any interfaces defined with indexed property setters? |
| 23:53 | <heycam> | or are all our array-like interfaces read only |
| 23:53 | <heycam> | ? |
| 23:54 | <smaug____> | storage stuff |
| 23:55 | <smaug____> | er, hmm |
| 23:55 | <smaug____> | no |
| 23:55 | <smaug____> | it is key-value |