IDE Minutes 2008-03-25
- Kevin Hakman, Aptana
- Jon Ferraiolo, IBM
- Phil Berkland, IBM
- Ted Thibodeau, OpenLink
- Ingo Muschenetz, Aptana
(continuing to walkthrough the wiki page at:
Kevin: We have concluded that there are some nuances with mixins that we haven't addressed yet.
Ingo: Have been talking with Dojo people. A couple of cases we don't express. Maybe I'll send email and then we can talk about it next week?
Kevin: OK. What can you say in general?
ACTION: Ingo needs report back about proposed changes for mixins.
(discussion about whether there can only be a single constructor within variable arguments or multiple constructors with different arguments. concluded the former: only one constructor per class, but can take variety of arguments)
(discussion about Aptana's format. concluded that there is a visibility=public|private, no scope, mode is deprecated, and then a different attribute that flags whether a particular API is "advanced", which means an IDE doesn't show that API for most users.
Ingo: We use the "advanced" attribute quite a bit. OK if it is our namespace extension instead of a standard feature.
Kevin: For JSON conversion, I prefer <method constructor="true">, with default of false.
Phil: 'constructor' attribute and 'name' attribute would be mutually exclusive
Ingo: Can you define mutually exclusive attributes in XSD? I think so.
Jon: I recommend RelaxNG for formal language definition. Definitely possible in RelaxNG.
DRAFT CONSENSUS: <methods>/<method constructor="true|false" visibility="...">
ACTION: Ingo needs report back about attribute that indicates "advanced".
Ingo: Child of 'class', 'method', 'property'. An element is better because we can have text content to say what to use instead.
Kevin: Perhaps useInstead markup for clarity?
Ingo: If an attribute, we might want it to be parseable.
Kevin: Anyone want an actionable list of pointers? Or is this too much for version 1
Jon: Too much for version 1. But we need to think through extensibility. One approach is that we only support text content today, but if we need to extend, we add child elements later.
DRAFT CONSENSUS: <deprecated> where child content is just text
Ingo: How to specify localizable content?
Jon/Kevin: We have an open issue on that across the whole language
Ingo: Maybe have IDs on each localizable element, or use $ for localizable strings
Kevin: Or @something@
Phil: Allow HTML?
Ingo: Has to be valid XML
Jon: What if the content includes advanced HTML features such as canvas or SVG that aren't supported universally yet? Just do your best job, and put burden on authors to include snippets that are portable?
Kevin/Ingo: Can use CDATA for non-well-formed HTML
Kevin: What about transcoding into JSON?
Jon: Possible, but not sure how hard. It's just a subset of the bi-directional escaping requirements.
Phil: Javadoc might define a subset of well-known HTML tags
Ingo: An example might use a wide variety of features
Kevin: What is description a child of?
(class, method, property, parameter, returns)
Jon/Ingo: Therefore, <returns type="..."><description>some text</description></returns>
Jon: Implicit <div> around everything in the description
(discussion that concluded that CDATA is only needed when content breaks XML)
DRAFT CONSENSUS: <description> can take HTML, if it breaks XML must wrap in CDATA, tool makes best effort to render, content is snippet that goes into an implicit DIV, burden on author to use a portable subset, will recommend and provide pointer to a portable subset
ACTION: Jon to research where a portable subset of HTML is defined such that we can reference it
Jon: What does this mean for JS?
Kevin: Let's skip until Bertrand is here
Ingo: Yes, but should be <examples>/<example>. Sometimes there are multiple examples.
Jon: Is an example always a <pre>
Ingo: Up to author to include any <pre>
Jon/Ingo: Implicit DIV around the example
Jon: Assume it is HTML if no namespace is declared.
DRAFT CONSENSUS: <examples>/<example>. Can take HTML like <description>. (See above)
Ingo: We should do like what is in Aptana's format, but clarify description.
Jon: What is type? Everywhere else the 'type' can only be an ECMA262 type
Ingo: What if parameter is an object?
Jon/Kevin: ECMA "Object" type, but use JSON Schema once it is defined for defining the Object more.
Ingo: But need to refer to other types in the document. For us, 'type' is either an ECMA type or a custom type defined elsewhere in the document
Jon: Need to think this through.
Kevin: Pick up next week with exceptions.
are we going fast enough?
Kevin: We are about halfway through this document. At this rate we won't finish this matrix until the end of April.
Phil: Remaining items should go faster.
consensus: for now, let's keep going 1 hour per week and see how we progress