Re: [sv-bc] Virtual interface resolution

Mark,

Thanks for the good issue summary and comments.

Along with you, I agree that I tend to prefer the "bind early" and
simply say that
the use of an interface name within a virtual type creates an "import
like" dependency
on the interface. So the interface must exist and must be *identical*
to the one
at compile time in order for it to be legal. As you note, that does
impact configurations
and other forms of (arguably) legal but difficult composition issues
such as compiling
a virtual interface reference prior to the interface existence.

There are likely still some issues to consider in that space however.
For example,
if a virtual interface to a parameterized interface exists, can
compile/elaboration
require that some instance of the interface be elaborated "on the side"
in order
for the package to compile? If not, there are likely issues related to
various bits
of typing and visibility. For parameterized classes for example, the
use of the
parameterization as a type implies elaboration of the type even if no
object
instances are created. How does that map to interfaces?

I think that those questions need to be looked at very carefully if we
want to
go in this direction. It is likely the most tractable direction, but it
still is certainly
not trivial.

Gord.

On 1/28/2011 3:06 PM, Mark Hartoog wrote:
>
> I have attached a PDF outlining the problem, possible solutions, and
> my thoughts on what would be the best alternative.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.