Path: news.daimi.aau.dk!jlk From: jlk@daimi.aau.dk (J|rgen Lindskov Knudsen) Newsgroups: comp.lang.beta Subject: Re: unusual inner Date: 2 Aug 1995 13:47:43 GMT Organization: DAIMI, Computer Science Dept. at Aarhus University Lines: 65 Message-ID: <3vnvlv$2ue@belfort.daimi.aau.dk> References: <3ulin4$h07@rs18.hrz.th-darmstadt.de> <3uvr75$5e3@belfort.daimi.aau.dk> <3v5451$12j2@rs18.hrz.th-darmstadt.de> <3v7t9n$147f@rs18.hrz.th-darmstadt.de> <3vngqc$12cu@rs18.hrz.th-darmstadt.de> Reply-To: jlknudsen@daimi.aau.dk (Jorgen Lindskov Knudsen) NNTP-Posting-Host: lithium.daimi.aau.dk Concerning overwriting vs. specialization in connection with virtuals in BETA, then it have been a deliberate design decision, that subclasses should be 'under the control' of the superclasses, implying that virtuals (as well as, say, variables in C++), cannot be overwritten in subclasses. Part of the philosophy is the ability to construct frameworks where the semantics etc. of the framework can be assured by the superclasses, since no overwriting of virtuals can be written to invalidate the soundness of the framework. Naturally, if one have been trained in solving design problems by _not_ correcting the design, but by hacking a solution, this language design decision seems like a straitjacket. So what can we do. One way it to use the strategy discussed by Kai Petzke in a previous posting. It works. But with a slight overhead. Another solution is to use a totally different BETA language mechanism, namely dynamic pattern references (pattern variables). Assume, you want to have something like (BETA-like C++ syntax :-): P: class (# vp: virtual (# enter ... do ...(1)... exit ... #) #); PP: class P(# vp: redefine (# ...(2)... #); #) In BETA, you can achieve this effect by: P: (# vpSignature: (# enter ... do inner exit ... #); vp: ##vpSignature; vpp: vpSignature(# ...(1)... #); init:< (# do vpp##->vp##; inner #); #); PP: P(# newvpp: vpSignature(# ...(2)... #); init:< (# do newvpp##->vp##; inner #); #) Invoking vp on instances of P will execute ...(1)..., whereas invoking vp on instances of PP will execute ...(2)... - assuming that the instances are initialized by invoking the init. Even 'on the fly' redefinition will now be possible: aPP: @PP; ... (# anothervpp: vpSignature(# do ...(3)... #) do anothervpp##->aPP.vp## #) The third solution is naturally to correct the design :-) Regards, -- Jorgen Lindskov Knudsen, Computer Science Department, Aarhus University Ny Munkegade 116, DK-8000 Aarhus C, DENMARK E-mail: jlknudsen@daimi.aau.dk, Phone: +45 89 42 32 33, Fax: +45 89 42 32 55