Re: Problems with visibility of implicit function...

[cwarack@cs.usafa.af.mil (Chris Warack <sys mgr>)]

In article <4q67nn$sp5@goanna.cs.rmit.EDU.AU>, Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes:
|> I've got some problems calling an implicity declared function
|> which is hidden by an explicity declared one. I've tried
|> renaming, only to end up with infinite recursion. Is the
|> implicity declared function "hidden from all visibility"?

Yes

|> --------------------------------------------
|> package lists is
|> 	type list is private;
|> 	
|> 	function full(item:list) return boolean;
|> private
|> 	...
|> end lists;
|> 
|> with lists;
|> package stacks is
|> 	type stack is private;
|> 	
|> 	function full(item:stack) return boolean;
|> 	
|> private
|> 	type stack is new lists.list;
|> 	-- inherited & implicitly defined full...
|> 	-- function full(item:stack) return boolean;
|> end;
|> 
|> package body stacks is
|> 
|> 	function full(item:stack) return boolean is
|> 	begin
|> 		...what?
|> 		should i just call on lists.full?
|> 	end;

There are at least three ways to go with this:
  1) Use a different name for Stacks.full
      -- you can then complete the visible definition by a renaming
         declaration in the body
  2) Use a tagged type for lists and extend it for stacks (probably not
     good design in this situation).
  3) call lists.full -- return Lists.Full(Lists.List(item)); to replace
     "what?" above.
     
    Does any compiler optimize case three into calling Lists.Full directly
    in case 3?  (e.g., giving Stacks.full the same linker symbol...?)

|> end stacks;
|> 
|> 
|> BTW WRT Annotated LRM, 8.5.4(8.g), what do alligators have to
|> do with squirrels?  ?:-)
|> 
|> Dale

-- 
Christopher A. Warack, Capt, USAF  cwarack@cs.usafa.af.mil (719) 472-2401
Computer Science Department, US Air Force Academy
This content in no way reflects the opinions, standards, or policy
of the USAF Academy, or the US government.