Xref: utzoo comp.lang.eiffel:601 comp.object:803
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!sunic!enea!helios!kim
From: kim@helios.enea.se (Kim Wald`n)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Eiffel cleanup #2: Doing away with void references
Message-ID: <KIM.90Jan19202532@helios.enea.se>
Date: 19 Jan 90 19:25:32 GMT
References: <227@eiffel.UUCP>
Sender: kim@enea.se
Organization: Enea Data AB, Sweden
Lines: 103
In-reply-to: bertrand@eiffel.UUCP's message of 17 Jan 90 08:25:32 GMT

In article <227@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:


>       No you see how the problem of routines applicable to void
>   references is addressed: such routines occur rarely enough, and
>   are special enough, that they should be added to your local version
>   of HERE.


And also exported in HERE, I suppose?

When trying to figure out how this would work, I found that the universal
model, as described in the reference manual, is not very clear:

1.

	p. 171 states:
		Every class which has no Inheritance clause is understood
		to have an Inheritance clause of the form

		inherit
			HERE

	Does this mean that a non-empty inheritance clause in the 
	topmost class, like
		
		class TOPMOST export ...
		inherit
			ANY
				rename out as basic_out
		feature ...

	also, as a side-effect, hides the local features of HERE from TOPMOST
	and all its descendants?

	If so, a standard way of renaming features from ANY would rather be:
		class TOPMOST export ...
		inherit
			HERE
				rename out as basic_out
		feature ...

	Or perhaps the text should be interpreted:
		Every class which has no inheritance clause 
		(or only inherits from ANY) is...


	By the way, has anybody actually tested a non-empty class HERE?
	I tried to check out its export behavior by adding a feature:

		class HERE
		inherit
			ANY
		feature
			hi is
				do
					io.putstring("hi");
					io.new_line;
				end;
		end -- class HERE

	But then my simple hello-program wouldn't compile.
	"es" complained:
		"basic: Export clause lists undefined feature: hi"
	and stopped.

	Trying various explicit exports of "hi" didn't seem to help.


2.

	p. 173 argues that the features of class ANY are always available
	to all classes, both in qualified and unqualified form,
	since ANY uses selective export to ANY itself.

	Thus, "y := p.out" is valid in any class C (for non-void "p").

	This seems a very strange line of reasoning to me.

	First, if "p" is of type P, it should be the export clause of P 
	that decides whether "out" is remotely available to C, and not
	the export clause of any proper ancestor, like ANY.

	Second, selective export is defined on p. 65 as a simple restriction
	to general export, so "export X {ANY}" should mean exactly the
	same as "export X", so the section doesn't make sense.

	(Am I missing some subtle point here, or is the manual text just
	the sunny effect of repeated inheritance from class Zinfandel :-)


3.

	One might argue that the theoretical form

		class NONE export
			repeat HERE ...
	
	is not quite correct, since the "repeat" clause would only be valid
	where HERE is a direct parent of NONE (p. 64)


Besides this, the proposed solution looks elegant, as always.


-- Kim Walden
Enea Data, Sweden
kim@enea.se