IDE Minutes 2008-04-01
- Kevin Hakman <khakman(at)aptana.com>, Chair
- Phil Berkland <berkland(at)us.ibm.com> representing Eclipse ATF project
- Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
- Ingo Muschenetz <ingo(at)aptana.com>
- Lori Hylan-Cho <lorihc(at)adobe.com>
- Stew Nickolas <nickolas(at)us.ibm.com> <scribe>
- Jon Ferraiolo <jferrai(at)us.ibm.com>
Kevin: API Metadata, we are about 1/2 through the matrix, working through definitions within the API metadata,
- Blue means draft consensus
- Red means questions or work-in-process
Jon: Question from email last week, Bertrand objected to the overload constructor attribute on a method
Jon: I'm OK with going back to the original proposal Kevin: Well the constructor is just another method, I’m ok with either approach, we can easily revert back to original to have a constructor element
Ingo: Should it be only a single constructor?
Bertrand: Only one constructor?
Kevin: Single constructor then
Ingo: How about the case of a constructor or method that have different signature?
Bertrand: We use optional parameters as well as different types, capture the required as overloads
Kevin: So we are discussing the ability to have redundant lists of methods and constructors that are useful for documentation and have different parameter combinations
Jon: That places a burden on IDE to define multiple definitions of a method
Kevin: So, fully redundant metadata that varies if list of parameters and types for a method or constructor then...
Kevin: Does this introduce a redundant code assist problem?
Ingo: The IDE has to look twice
Kevin: IDE vendors sound OK?
Ingo: Aptana is already handling
Bertrand: We are already supporting the redundant format
Jon: If a method has a description and if you repeat definitions with different parameters, then you have to repeat the description
Ingo: We should enable the flexibility not mandate it.
Kevin: IDEs have to support it though
Kevin: Having a constructors element and constructor elements within that AND allowing multiple methods with the same ID with different signature, consensus?
Ingo: The advanced attribute is used by Aptana to define protected methods(ed:?), its used for code assist
Bertrand: Recommend add advanced through extensibility
Ingo: The proposed values for visibility are: public, private, protected, internal, protected-internal
Jon: One more thing, where we have the Ecma type Object we can also have a class name, that is a typed value
Ingo: ya we call it typed values in Aptana
Jon: says it works (e.g. type of class)
Kevin: Type attributes, e.g. return type, Ecma types plus class names, any objections? none. draft consensus
Jon: Still need to research on portable HTML, skipped for this meeting
Kevin: We need to work on a common format for the event, the proposal in the matrix is consistent with Microsoft
Bertrand: We simply need to describe the name of the event, data and handler signature
Jon: Explain event?
Bertrand: Any event a component exposes, similar to OpenAjax topics and message
@event + JS document
Ingo: Is the event tag separate from the method tag?
Bertrand: No, then implementation of event may be different for each toolkit
Jon: so, Event metadata associated at the class level NOT a method?
Kevin: I heard the metadata is associated with methods as well, there is confusion here
Bertrand: Events are associated with one or more methods
Kevin: Are event defined at class level or defined and association at method level? if so, they are just redundant @ the method level,
Ingo: In JS docs events @ methods are redundant
Bertrand: Event may also be triggered externally, therefore not associated with a method
Kevin: Is the event a primary element then?
Bertrand: The event concept may have different implementation? how to we map it generally?
Jon: Break it down, assign XML markup, method basis @ event mapped to event element
Jon: Event tags under method?
Kevin: Then we have attributes for name and payload
Jon: yep, Name and type of event
Kevin: Type is Ecma or class name
Ingo: JS doc @ event of type after that
Kevin: name and type of the event, @event foo typeBar
<event name='foo' type='Object or classname or prmitive'/>
Bertrand: What if parameter list of the of handler is more complicated (e.g. sender, payload)
Jon: Can we put in text within the description?
Bertrand: Maybe, but.... not interesting to have the event at all, if too complex, maybe ok for V1., maybe use the extensibility mechanism?
Jon: Yes, lets use the extensibility, this feature doesn't seem to be used too much in JS libraries,
Bertrand: on the other hand will not capture, events
Jon : The Widget metadata capture event
Kevin: At the application level, yes
Jon: Allows the widgets to advertise the events it publishes and consumes
Bertrand: That assumes the OpenAjaxHub
Jon: Widget metadata not consistent and needs to be fixed
Kevin: Confused about listening and publishing
Bertrand Whole events on, too complex
Ingo: Yahoo and Google use @event tag, check it out
Kevin: More research
Bertrand: Microsoft uses
Kevin: Need to research and identify common approach
Bertrand: Looks like javadoc, maybe not mandatory at method level
Kevin: Proposal Exceptions node, exception element with types
Phil: Do we need multiple exceptions? Given there is only one catch?
Bertrand: I disagree; only one exception will quickly lead to people throwing an Error, used to declare something more specific
Kevin: Good, draft consensus then
Ingo: @project description node, description of library
Kevin: Overview node? Provide context for metadata?
Kevin: Lets put a description tag on outer most tag, draft consensus
Kevin: Redundant, draft consensus no mapping
Indo: The id is used to reference documentation on another file via @id
Jon: We are flattening the documentation so this is not necessary
Indo: Yes, merged version of JSdocs + location
Kevin: Draft consensus is to NOT support
Kevin: draft consensus is to ignore the ignore
Ingo: @extends with possibility of multiple type indicates what you extends, ancestor
Kevin: Attribute of classes on the constructor
Jon: The @augments is similar, isn't the mixin proposal going to address this? (from Ingo)
Kevin: So will the ancestor handle the @extends?
Kevin: Anyone object to @inherits being redundant, given we have already agreed to that?
Jon: Agree tentatively, waiting for mixin proposal from Ingo
Kevin: We seem to be about 60% through, more easy tactical items I see as we go, should we meet twice a week for the next month?
Kevin: Our objective is to be done by summary end
Lori: no objections
Kevin: Tuesday & Thursday same times (1:00pm PT, 3:00pm CT, 4:00pm CT)
Kevin: I'll send out updated schedule