IDE Minutes 2009 01-06

From MemberWiki

Jump to: navigation, search




  • Jon Ferraiolo, IBM
  • Phil Berkland, IBM
  • Kin Blas, Adobe
  • Lori Hylan-Cho, Aptana
  • Nitin Dahyabhai, IBM
  • Bertrand Le Roy, Microsoft

Original Agenda


Rechartering voting ends today

Jon: Put on the agenda as a reminder. Everyone on the call has voted already, I believe.

Aren't superclass and <ancestor> redundant?

Jon: We resolved this in email. 'superclass' has been removed. I left a red note in the spec temporarily until this phone call to give people one last chance to review. Any comments?


Separating out Gadgets features into a separate spec

Jon: I finally got around to this old action and moved all of the Gadgets features out into a separate wiki page for the Gadgets TF to work on:

What products are supporting __WID__ right now?

Jon: Kin responded that Dreamweaver isn't using this. I didn't hear from anyone else. I moved __WID__ out of the main metadata spec onto the supplemental gadgets spec. Nitin, is Rational using __WID__?

Nitin: I don't remember using it.

Jon: Could you please check? If you are using it, then send email to the group.

Questions about 'visibility' attribute

Jon: I believe we concluded in email that JavaScript cannot enforce private, protected and other things, and instead it is the IDE that is supposed to implement those notions. Right?

Nitin: Yes. But why is there a protected-internal versus just a comma-separated list.

Bertrand: It is the only actual combination that can happen

Nitin: OK

Jon: The five values we have, public|private|protected|internal|protected-internal, are from .NET. I don't remember what Java has.

Bertrand: Should be similar.

Nitin: I don't remember an "internal"

Bertrand: I believe the equivalent in Java is "package"

(Lengthy discussion where Jon says "internal" needs to be well-defined. We talked about whether internal means within the same file or within the same namespace, and if namespace, whether it is the closest namespace, where in a.b.c, c would be closest, or topmost namespace, where in a.b.c, a would be topmost. We also talked about potentially dropping internal and protected-internal. Bertrand says he would use internal and protected-internal. Phil and Lori were inclined to keep it. Phil and Lori indicated they might not support it right away. We talked about whether tools that don't support internal should map to public or private. Public is the default. We concluded that treatment of unknown/unsupported values is an implementation-specific decision.)

RESOLUTION: keep the five values, but define 'internal' to mean within same top-level namespace.)

Questions about <event> element:

RESOLUTION: We agreed with what was said on email

  • (1) <event> should be child of <mixin> and <interface>, also.
  • (2) Bertrand/Jon feel we can leave registerHandlerPattern and unregisterHandlerPattern as is.

<ancestor> element questions:

RESOLUTION: We agreed with what was said on email

  • Summary: Jon/Steve/Bertrand prefer (b) adopt a loose model where "anything goes", where a <mix> or <ancestor> can refer to any of the following: <class>, <interface>, <mixin>, <singleton>.

Use Hub 1.1 for samples?

(Agreement that we can see if Hub 1.1 will produce some good samples for the spec)

Personal tools