| 06:45 | <annevk> | TabAtkins: it depends whether his name is Dutch, e.g. Swedish would sort under v iirc, but gsnedders is entirely correct when it comes to Dutch :-) |
| 07:43 | <Ms2ger> | nl-NL, that is |
| 09:20 | <joa_> | Hi, are the WebIDL definitions shown on *.spec.whatwg.org available somewhere? I couldn't find them in the GitHub repo |
| 09:32 | <gsnedders> | annevk: well, TabAtkins did say Dutch names. So I was assuming he meant Dutch. (But yes, Swedish would sort under "v") |
| 09:33 | <annevk> | joa_: what do you mean? |
| 09:33 | <annevk> | joa_: we don't distribute standalone IDL files |
| 09:38 | <joa_> | annevk: Is there an automated process that generates dom.spec.whatwg.org for instance? |
| 09:39 | <annevk> | joa_: I write HTML in Overview.src.html, run make, which generates Overview.html, that's it |
| 09:40 | <joa_> | annevk: Alright, thank you! |
| 11:02 | <gsnedders> | SteveF_: when do you want a response by? |
| 11:34 | <SteveF_> | gsnedders: end of week or start of next would be good |
| 11:36 | <gsnedders> | SteveF_: right, sure thing |
| 11:37 | <SteveF_> | gsnedders: Thanks! |
| 11:39 | <SteveF_> | me/ was looking at your flickr photos from TPAC 2008 and reminiscing |
| 11:39 | <gsnedders> | '08? I was thinking it was '09. But I guess it must've been '08, wow. |
| 11:44 | <gsnedders> | It's kinda sad I've not managed to make it since. Oh well, maybe next year… |
| 11:45 | <gsnedders> | Guess we'll find out where it's planned to be soon enoguh |
| 11:45 | <gsnedders> | *enough |
| 11:46 | <jgraham> | http://www.w3.org/2015/11/TPAC/ |
| 11:46 | <wilhelm> | Sapporo. |
| 11:46 | <gsnedders> | oooh! |
| 11:46 | <gsnedders> | I was /going/ to say I'd only definitely go if it were in Europe. But okay, maybe you have me. |
| 11:49 | <wilhelm> | Haven't been to Hokkaido yet. This is a good excuse. |
| 12:05 | <gsnedders> | Don't tempt me to try and get there without flying. :) |
| 12:07 | <wilhelm> | I've done 80% of the overland route before. Highly recommended. |
| 12:07 | <gsnedders> | idk, it's more the whole perception and legality of LGBT people in Russia that makes me uneasy about doing so |
| 12:10 | <wilhelm> | Valid point. |
| 12:11 | <gsnedders> | That's the sort of reason that actually puts me off from doing so. The other stuff just makes it difficult. |
| 12:58 | <rubys> | annevk: ping? |
| 12:58 | <annevk> | rubys: here |
| 12:59 | <rubys> | Can I get you to explain the expected results for this test: http://intertwingly.net/stories/2014/10/16/urltest-results/61a4a14209 ? |
| 13:00 | <rubys> | I get the same results as ie, opera, and rust. |
| 13:00 | <annevk> | Yeah, per spec it is "0xc0.0250.01" at the moment |
| 13:01 | <annevk> | I can update web-platform-tests if you want |
| 13:01 | <rubys> | One more question first: http://intertwingly.net/stories/2014/10/16/urltest-results/f3382f1412 |
| 13:03 | <rubys> | Background on why I'm asking: I have a JavaScript implementation that passes 254/256 tests. I should be ready to post it today or tomorrow. |
| 13:04 | <annevk> | rubys: per the specification parsing that should return failure, the reason being that there's a % left in step 6 of the host parser afaict |
| 13:05 | <annevk> | rubys: so results for testdata seem correct |
| 13:05 | <rubys> | I get "0xc0.0250.01." |
| 13:06 | <annevk> | "%3g" should remain "%3g" afaict |
| 13:06 | <annevk> | How do you normalize that away? |
| 13:06 | <rubys> | my bad, I pointed to the wrong test. This is the one I meant: http://intertwingly.net/stories/2014/10/16/urltest-results/bc6ea8bdf8 |
| 13:07 | <annevk> | Isn't 0xc0.0250.01. what testdata says? |
| 13:08 | <rubys> | Hmm. looks like it. Let me check |
| 13:20 | <rubys> | ok, found the bug in my code; now I have 255/256 tests passing, and you agree on the one failure |
| 13:20 | <annevk> | \o/ |
| 13:21 | <annevk> | (seems like we need more tests) |
| 13:21 | <rubys> | always :-) |
| 13:22 | <rubys> | my code is probably very buggy in that I did test-driven development, only consulting the spec when I had questions. I also have more work to do in encoding, but it is at the point that it is worth publishing for discussion. |
| 13:23 | <rubys> | it also may be worth mining for ideas in the upcoming spec functional rewrite |
| 13:24 | <rubys> | meanwhile, a sneak peek: http://intertwingly.net/stories/2014/10/20/Url.xhtml |
| 13:25 | <annevk> | rubys: you have your own tool or is that bikeshed? |
| 13:26 | <rubys> | http://pegjs.majda.cz/ => https://twitter.com/peg_js/status/329493915881320448 => http://bottlecaps.de/convert/ |
| 13:26 | <annevk> | Note that with functional I didn't necessarily mean declarative |
| 13:27 | <rubys> | let's discuss when I have something concrete posted, should be today or tomorrow |
| 13:28 | <rubys> | the grammar I've developed is only a small part, there is a lot of logic, and a Url class. |
| 13:29 | <rubys> | in the process, all flags are eliminated, and with only one exception, the only scheme checks are of the form "if (this.scheme == base.scheme)" |
| 13:30 | <rubys> | but again, it will be easier to discuss with running code. |
| 13:30 | <annevk> | You have the API implemented as well? |
| 13:30 | <Ms2ger> | Get back to work, then ;) |
| 13:30 | <annevk> | The "relative flag" is mostly for the API |
| 13:31 | <rubys> | parts of the API. I should be able to do all of the "setters" without a flag. |
| 13:34 | <annevk> | I wonder if the POSIX DNS layer also does the crazy IPv4 parsing inside IPv6... |
| 13:35 | <gsnedders> | pretty sure POSIX leaves most of it undefined |
| 13:43 | <annevk> | It's somewhat annoying we rely on such a subsystem |
| 13:43 | <annevk> | Fortunately it mostly works |
| 14:37 | <rubys> | That was easier than I thought it would be: http://intertwingly.net/projects/pegurl/liveview.html |
| 15:07 | <annevk> | cool |
| 15:08 | <annevk> | rubys: peg? |
| 15:16 | <jgraham> | http://pegjs.majda.cz/ I presume |
| 15:18 | <rubys> | http://intertwingly.net/blog/2014/10/21/pegurl-js |
| 15:23 | <annevk> | doh |
| 15:29 | <annevk> | rubys: it's a bit unclear to me how you envision those railroad diagrams to become the normative part of the spec |
| 15:30 | <rubys> | Did I say normative? What I meant was to follow the lead of CSS. |
| 15:31 | <annevk> | Ah okay, this would be for the URL writing section? |
| 15:31 | <rubys> | Possibly. However these diagrams also capture invalid URL productions too. Needs more thought. |
| 15:32 | <annevk> | Just looked at http://dev.w3.org/csswg/css-syntax/ again, I guess I see what you mean |
| 15:33 | <rubys> | annevk: I'm assuming that you won't be in the bay area next week? |
| 15:33 | <annevk> | correct |
| 15:33 | <rubys> | bummer |
| 15:34 | <annevk> | I'm in Portland Dec 1-6, that's it for work travel this year |
| 15:36 | <rubys> | At this point, I'm quite willing to commit to putting substantial effort into contributing to the WHATWG URL Standard; any guidance on how to do that without ruffling feathers or wasting anybody's time would be appreciated. |
| 15:37 | <annevk> | I want railroad diagrams. I want to switch to Bikeshed. I'm not sure if railroad diagrams should just be for writing or should be for the parser or for both. |
| 15:38 | <annevk> | The way I was thinking of rewriting the parser would be in the form of several functions, each parsing its own bit, operating on the same underlying input string and buffers. With the option for some of those functions to be invoked standalone so the API can use them. |
| 15:38 | <annevk> | None of this I'm actively working on at the moment. I do actively fix API bugs as that's actually implemented. |
| 15:39 | <rubys> | my parser is a set of functions, each returning back a POJO (corresponding to a dictionary or hash in other languages) |
| 15:42 | <rubys> | Unless you strongly object, I'll try to produce a number of pull requests. Be forewarned: some might be substantial. We can use github facilities to discuss the pull requests. |
| 15:43 | <annevk> | I certainly won't object to getting PRs :-) |
| 15:45 | <rubys> | Cool. This will likely fill my dead time on the plane ride to the left coast on Sunday. |
| 15:52 | <TabAtkins> | annevk: I currently only use railroad diagrams for non-normative illustrations of syntax. |
| 15:53 | <annevk> | I think that makes sense, I wouldn't want to use them for something else personally |
| 15:53 | <TabAtkins> | They could probably be used normatively, but you need something with real grammar, as they're not good for error-correcting grammars. |
| 15:58 | <rubys> | There isn't much error correcting in the URL grammar; most of it is in dealing with mal-formed URLs with an @ sign in them. |
| 16:01 | <TabAtkins> | Any error-correction usually pushes the actual accepting grammar to excessive wideness/verbosity to be usefully expressed as a railroad diagram. |
| 16:02 | <TabAtkins> | You don't have to be as extreme as HTML or CSS, whose accepting grammars are .* |
| 16:06 | <rubys> | TabAtkins: I don't see much of that in URL. http://intertwingly.net/stories/2014/10/20/Url.xhtml |
| 16:07 | <TabAtkins> | I only see @ showing up in one production in the whole thing. That right? |
| 16:08 | <rubys> | The error-correction is done elsewhere. Search for '@' in http://intertwingly.net/projects/pegurl/url.pegjs |
| 16:09 | <Domenic> | JakeA: public-webapps high-five |
| 16:10 | <rubys> | Note: that logic also contains the "prepend %40" that I believe is unnecessary for web compat. Example: http://intertwingly.net/stories/2014/10/16/urltest-results/1bdb1f0518 |
| 16:11 | <rubys> | TabAtkins: any guidance on what it would take to convert a document from Anolis to Bikeshed? |
| 16:12 | <TabAtkins> | rubys: Most of Anolis converts to Bikeshed just fine, as Anolis is *also* derived from Bert's preprocessor. The big problem is linking, because anolis is really verbose about it. |
| 16:12 | <TabAtkins> | That said, I find converting things to be relaxing, and would be happy to help. |
| 16:13 | <rubys> | Bikeshed seems to be the path of least resistance to incorporating railroad diagrams; at the moment, however, I know neither Anolis nor Bikeshed, but I learn fast :-). |
| 16:13 | <annevk> | rubys: something like http://@@@test.com seems interoperable between Firefox and Chrome |
| 16:14 | <annevk> | rubys: not sure why that test fails in Firefox, might be related to the leading :: |
| 16:15 | <rubys> | annevk: I'll note that http://@@@test.com doesn't require pre-pending; merely percent encoding. |
| 16:16 | <rubys> | It's the active reordering that seems wrong to me. |
| 16:34 | <annevk> | rubys: if you don't do that you'd have to process the string twice, no? |
| 16:34 | <annevk> | hmm but that's already the case |
| 16:41 | <annevk> | rubys: I guess if you use a different encode set that could work |
| 16:42 | <rubys> | I'll experiment and make a concrete proposal. |
| 16:45 | <rubys> | One thing I like about the grammar I produced is that it makes quirks more easy to spot. |
| 16:46 | <rubys> | Example of clean: |
| 16:46 | <rubys> | if (scheme) { result.scheme = scheme[0].toLowerCase() } else { result.scheme = base.scheme } |
| 16:46 | <rubys> | Example of ugly: |
| 16:46 | <rubys> | host = host.split('@'); result.host = host.pop(); if (host.length > 0) { if (!auth) auth = {username: ''} if (auth.password != null) { auth.password += Array(host.length+1).join("%40")+host.join('') } else { auth.username += Array(host.length+1).join("%40")+host.join('') } }; |
| 16:47 | <rubys> | Note: in my implementation, I don't process the string twice, instead I do a fixup after parsing. |
| 16:48 | <rubys> | ... but as long as I get the same results, all should be good, right? |
| 16:50 | <rubys> | Hmmm. Why doesn't the URL Standard include "Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)", like the HTML spec does? |
| 16:53 | <JakeA> | Domenic: :D just read your email |
| 16:56 | <Domenic> | rubys: my guess is an oversight. I love that text. |
| 16:56 | <Domenic> | annevk: how do i get a @thestreamsstandard bot |
| 17:09 | <rubys> | https://github.com/whatwg/url/pull/7 |
| 17:22 | <mathiasbynens> | Domenic: register the twitter account and set up a github hook |
| 17:22 | <Domenic> | mathiasbynens: is there a built-in GitHub hook? |
| 17:22 | <mathiasbynens> | Domenic: https://github.com/whatwg/streams/settings/hooks/new?service=twitter yep |
| 17:23 | <Domenic> | well that's nice and easy |
| 17:23 | <mathiasbynens> | I hereby call dibs on at least one (1) Streams sticker btw |
| 17:26 | <Domenic> | ^_^ |
| 17:48 | <Domenic> | Aight, well, pretty boring right now, but https://twitter.com/streamsstandard |
| 18:41 | <pluma> | Is lists.whatwg.org down? |
| 18:44 | <rubys> | @TabAtkins: FATAL ERROR: IDL SYNTAX ERROR LINE: 10 - skipped: "iterable<USVString, USVString>" |
| 19:10 | <hober> | pluma: yes, permanently |
| 19:10 | <pluma> | hober: but the list still exists? |
| 19:14 | <pluma> | hober: I just want to make sure I don't need to unsubscribe. |
| 19:19 | <Hixie> | pluma: yup, list is still up. archives are at lists.w3.org/Archives/Public/public-whatwg-archive/latest |
| 19:19 | <Hixie> | pluma: if you want to unsubscribe, there should be an e-mail address in the e-mails from the list |
| 19:26 | <pluma> | Hixie: yeah, but I subscribed with an alias, so it'd have been easier to unsubscribe via the web interface. |
| 19:27 | <pluma> | Hixie: I'll do it the old-fashioned way then. |
| 19:41 | <Hixie> | pluma: you can actually get to lists.whatwg.org if you really want to, you just need to clear your cache entirely first (or use a browser that's never visited *.whatwg.org) |
| 19:41 | <Hixie> | pluma: the underlying problem is we don't have a way to make lists.whatwg.org work over https, because dreamhost |
| 19:42 | <pluma> | Hixie: thanks, but I already unsubscribed via mail. |
| 19:42 | <Hixie> | cool |
| 19:48 | <TabAtkins> | rubys: Sorry, haven't yet updated Bikeshed to the new idl stuff. I'm pretty sure plinss has fixed those in widlparser, one sec while I pull it down. |
| 19:49 | <TabAtkins> | rubys: Okay, updated. Pull the new stuff down and see if it worked; if not, I'll bug plinss to update. |
| 19:52 | <rubys> | @TabAtkins: on to the next error. |
| 19:52 | <rubys> | FATAL ERROR: Functions/methods must end with () in their linking text, got 'dom-URL'. |
| 19:52 | rubys | looking to see if I can figure this one out myself |
| 19:53 | <TabAtkins> | Now you're running into the "anolis has a weird data-model for links" thing that the conversion will have trouble with. |
| 19:53 | <rubys> | thing like <span title=dom-URL>? |
| 19:53 | <TabAtkins> | Yeah. |
| 19:54 | <rubys> | what should that look like? I'm good with global search and replace. |
| 19:55 | <TabAtkins> | Well, move the dom-URL into the ID, then either remove the title or set it to "URL()". |
| 19:55 | <TabAtkins> | That way you can autolink to it with just {{URL()}} |
| 19:56 | <rubys> | ok, I think I need to spend some quality time with the bikeshed docs. |
| 19:56 | <TabAtkins> | Yeah, Bikeshed's autolinking stuff is rich and easy to use when you start with it, but converting from something with different semantics can be a little tricky. |
| 19:57 | <TabAtkins> | (I'm about to head to lunch if you want me to help.) |
| 19:57 | <rubys> | I'll try to get as far as I can. I can always look at the anolis output for clues as to what the desired output should look like. |
| 20:47 | <Hixie> | anyone know anything about registerElement()? |
| 20:48 | <Hixie> | i'm trying to figure out http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3270 |
| 20:48 | <Domenic> | I kind of do |
| 20:48 | <Hixie> | specifically, why chrome says e.g. firstChild is on that x-foo element |
| 20:48 | <Domenic> | Ah |
| 20:48 | <Domenic> | Chrome has shitty WebIDL support |
| 20:48 | <Domenic> | They have been trying to move to accessors on the prototype for years |
| 20:48 | <Domenic> | and failing due to perf regressions |
| 20:49 | <Domenic> | there are epic bugthreads with patches being added and reverted all over the place |
| 20:49 | <Hixie> | ok so if it shouldn't have any of Element or Node on that x-foo element, in what sense is that element an element? |
| 20:50 | <Domenic> | wait maybe i missed the question |
| 20:50 | <Hixie> | could you do document.registerElement('x-bar', WebSocket) ? |
| 20:50 | <Domenic> | yeah sorry you are using for-in not Object.keys so I was talking about something compleeeetely different |
| 20:51 | <Domenic> | interesting i see what you're saying now |
| 20:51 | <Domenic> | i thought there was a requirement to have HTMLElement in your proto chain |
| 20:51 | <Domenic> | maybe it fails soft |
| 20:51 | <Domenic> | spec-reading time |
| 20:51 | <Hixie> | i don't see anything in the spec that would fix it up or enforce it, unless you pass null |
| 20:51 | <Hixie> | then it defaults to HTMLElement |
| 20:53 | <Domenic> | yeah |
| 20:53 | <Domenic> | i am having a hard time with all the terms |
| 20:53 | <Domenic> | "interface prototype object" etc. |
| 20:53 | <Domenic> | ah it's webidl-speak |
| 20:54 | <Hixie> | it's weird but the thing that hurts me the most reading that spec is the capitalisation of all the variables |
| 20:54 | <Domenic> | haha |
| 20:54 | <Domenic> | i'm going to call that a failed experiment |
| 20:57 | <Domenic> | Hmm Chrome people say that is related to the instance-not-prototype bug. |
| 20:58 | <Domenic> | so, Chrome bug. |
| 20:58 | <Hixie> | so if i do document.registerElement('x-bar', WebSocket), and i call my constructor, does it, like, open a TCP connection somewhere? |
| 20:59 | <Hixie> | "The prototype is already in-use as an interface prototype object" |
| 20:59 | <Hixie> | hmm, ok |
| 20:59 | <Domenic> | No, it'll just grab WebSocket.prototype |
| 20:59 | <Domenic> | oh, and maybe fail because of that |
| 21:00 | smaug____ | wonders why blink still has the perf issue with prototypes |
| 21:01 | <smaug____> | I guess blink could take Gecko's Webidl bindings ;) |
| 21:01 | <Domenic> | it's so embarassing |
| 21:12 | <Domenic> | [NoInterfaceObject, Exposed=(Window,Worker)] is a bit confusing. |
| 21:16 | <Hixie> | Domenic: why? |
| 21:17 | <Domenic> | Hixie: "exposed" apparently doesn't mean "exposed as a property on the global" like I assumed it would. |
| 21:20 | <Hixie> | i think it maybe depends on how the interface is then used? |
| 21:20 | <Hixie> | e.g. if you say A implements B, but B isn't exposed, then B won't be imported? |
| 21:20 | <Hixie> | i could be wrong |
| 21:24 | <Domenic> | it looks like it's more "contexts the interface can be used in" rather than "contexts it is exposed as a global property" |
| 21:25 | <Hixie> | it's also possible i used it wrong |
| 21:26 | <Domenic> | I'm actually looking at URLUtils |
| 21:29 | <Hixie> | ah |
| 21:39 | <TabAtkins> | Domenic: Before I comment on es-discuss, I'm totally confused about the Function.prototype[Symbol.referenceGet] value. |
| 21:39 | <Domenic> | TabAtkins: it's what makes iterable::map(fn) work |
| 21:39 | <TabAtkins> | In the other objects, the @@referenceGet property is a function that *does* something when you pass it the base value. |
| 21:40 | <TabAtkins> | But it doesn't seem to do anything for generic functions. |
| 21:40 | <TabAtkins> | The function ignores base and just returns the function? |
| 21:40 | <TabAtkins> | Oh wait, never mind. |
| 21:40 | <TabAtkins> | That's just the iterable::map part. The () part then *calls* that function. |
| 21:41 | <TabAtkins> | No, wait, still confused. |
| 21:41 | <Domenic> | hmm |
| 21:41 | <Domenic> | should it be return this.bind(base)? |
| 21:41 | <TabAtkins> | I think it needs to be, yeah. |
| 21:41 | <TabAtkins> | Otherwise there's no way for base to get intot he function. |
| 21:41 | <Domenic> | https://github.com/zenparsing/es-abstract-refs/issues/4 |
| 21:42 | <TabAtkins> | Ah, cool, someone else caught it. |
| 21:42 | <TabAtkins> | I'm not crazy, then. |
| 21:42 | <Domenic> | yeah somehow i just skipped over it and saw what i wanted to see |
| 21:45 | <TabAtkins> | Is there something special in ES that makes the foo.bar() form work, with `foo` bound to `this`? |
| 21:45 | <TabAtkins> | Maybe it was meant to invoke that somehow. |
| 21:47 | <TabAtkins> | (I don't know my way around the ES spec's very indirect definitions to find this out myself. It's a very confusing spec to read.) |
| 21:49 | <Hixie> | something special? |
| 21:49 | <Hixie> | in what sense? |
| 21:50 | <TabAtkins> | Like, foo.bar just returns the value of the "bar" property on "foo". But invoking it immediately, with foo.bar(), has the side-effect of binding foo to the "this" variable inside of bar. |
| 21:51 | <TabAtkins> | So maybe it was intended that foo::bar() have the same magic. |
| 21:51 | <Domenic> | TabAtkins: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-evaluatecall |
| 21:52 | <TabAtkins> | So the function returned by bar[Symbol.referenceGet](foo) (what the foo::bar syntax decomposes to) is also soft-bound to foo. |
| 21:52 | <Domenic> | And nah, if it's anything like https://people.mozilla.org/~jorendorff/es6-draft.html#sec-evaluatecall, it's meant to provide a convenient syntax for extracting bound methods too |
| 21:53 | <Domenic> | hmm although it's not that convenient if you can't omit the first part |
| 21:53 | <Domenic> | bind operator gives var bound = ::obj.method; |
| 21:53 | <Domenic> | this proposal only has var bound = obj::obj.method; |
| 21:53 | <TabAtkins> | This isn't really a binding operator. |
| 21:54 | <Domenic> | sure it's supposed to be a generalization of it |
| 21:54 | <Domenic> | and of relationships |
| 21:54 | <Domenic> | in both cases being a little more awkward than the original |
| 21:55 | <TabAtkins> | I mean that it doesn't do binding at all. It does "application of functions to objects in ltr order rather than nesting order". |
| 21:55 | <TabAtkins> | Which happens to accomplish something very similar to the old bind operator. |
| 21:56 | <Domenic> | it works alone |
| 21:56 | <Domenic> | var bound = obj::obj.method; |
| 21:57 | <TabAtkins> | Sure, it accomplishes that. (Though not as written, due to the probably-mistaken default implementation.) |
| 22:17 | <Hixie> | so uh |
| 22:17 | <Hixie> | how do you define properties in es6 classes? |
| 22:17 | <Hixie> | is that not a thing? |
| 22:18 | <Domenic> | get x() { ... } set x(v) { ... } |
| 22:18 | <Hixie> | is that not in the spec? |
| 22:18 | <gsnedders> | es6 classes are just silly syntax, bah! |
| 22:18 | <Hixie> | i can't find it anywhere |
| 22:19 | <Domenic> | https://people.mozilla.org/~jorendorff/es6-draft.html#sec-method-definitions |
| 22:20 | <Hixie> | oh, i see |
| 22:20 | <Hixie> | i assumed "method" meant, like, method :-P |
| 22:20 | <Hixie> | thanks |
| 22:21 | <Domenic> | yeah :-/ |
| 22:22 | <Hixie> | how about constructors? |
| 22:22 | <Hixie> | are those still in? |
| 22:22 | <Hixie> | i don't see those either |
| 22:22 | <Hixie> | even in methods! |
| 22:23 | <caitp-> | the constructor property of a class |
| 22:23 | <Hixie> | or is it just a method called "constructor" |
| 22:23 | <caitp-> | bingo |
| 22:23 | <Hixie> | k |