IDE Minutes 2008-04-01

From MemberWiki

Jump to: navigation, search
  • 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>

http://www.openajax.org/member/wiki/JavaScript_API_Comparison_Matrix

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?

Jon: That matches JavaScript, consistent with language conventions as well

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

Bertrand: Yep

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

@description

Jon: Still need to research on portable HTML, skipped for this meeting

@event

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

Jon: We have the topic as part of the widgets, don't we simply have to have the Javascript side document the metadata?

@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

@Exceptions

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


@fileoverview

Ingo: @project description node, description of library

Kevin: Overview node? Provide context for metadata?

Jon: @description

Kevin: Lets put a description tag on outer most tag, draft consensus

@function

Kevin: Redundant, draft consensus no mapping

@id

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


@ignore

Kevin: draft consensus is to ignore the ignore

@inherits

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

Retrieved from "http://www.openajax.org/member/wiki/IDE_Minutes_2008-04-01"
Personal tools