As Stephan Diehl [GK] wrote:
> To: gladius@compiler.kaist.ac.kr
> Subject: Re: On the semantics of SUPER,
>
> Also I have a semantics for your example,
> I think it is at least questionable if
> we should allow it:
> CLASS C [.. field Y ..]
> { A { SUPER.X IS Y } }
>
> Here we would change the value of the field X in the prototype
> of the superclass! This seems dangereous to me, but if the
> programmer wants to do it. The idea of super was to
> access a value of a super class and use it as in
>
> CLASS C [ .. field Y ... ]
> { A { Y IS SUPER.X
> Z IS SUPER.children[1]
> }
>
> At least we aggree on the meaning of SELF, do we?
>
> OK, I agree on writing two proposals, but we should
> think about how we combine these. Maybe we write one
> with an Annex of non-extensions but changes.
> I still hope we can implement everything on top
> of VRML, that's why I'll contact the EAI Working
> Group, maybe we can convince them to add some
> further hooks to the browser, e.g.
> there is an EventOutObserver but no EventInObserver
> in the EAI proposal, the latter would be
> needed to implement constraints.
>
> (Could you forward this and the previous mail
> to ooe-vrml@cs.uni-sb.de, I am using a text
> terminal to write this mail and didn't get
> a cc-option by the mail program)
>
> Thanks
> --Stephan
>
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sungwoo Park, (Castle-Help Naive) homepage : http://compiler.kaist.ac.kr/~gladius e-mail : gladius@compiler.kaist.ac.kr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -