Re: [sv-ec] Re: [sv-bc] Slides for name resolution face to face

From: Steven Sharp <sharp_at_.....>
Date: Tue Sep 25 2007 - 09:54:02 PDT
>I think that what you hope to have (or expect to have) is
>that given "obj.vintf.a.b.c" that "a.b.c" will be treated
>as a hierarchical reference *relative to* the actual
>interface instance referenced by obj.vintf.
>
>The only time in which you would care is if "a.b.c" ended
>up resolving upwards with respect to the actual instance.

I would NEVER expect this to resolve to an "a" that is not
directly inside the object referenced by "obj.vintf".

Upward searches are only for the starting point of a path,
never within them.  Gord is still tentative about stating
this, because it is a fairly recent realization.  I state it
as (what I thought was) an obvious fact about how it works.
The description of upwards refernces in the LRM does not talk
about upward searching except for the scope_name at the start
of the path.  

The previous subsection describes the full path name as the
concatenation of the names of the scopes that contain it,
separated by dots.  From context, it is clear that this goes
from outermost to innermost in sequence.  That and the fact that
it is stated to be unique does not allow for any backtracking
within the name.

The section talks about a name starting from the top.  It also
talks about one starting from the point in the hierarchy where
the name is used (which is just a degenerate case of an upward
name, described later).  Later there is a description of an upward
search for a scope name matching the first component in a name.
But nowhere is there any suggestion that a name after a dot can be
anything but a branch directly inside the scope of the previous name.

Perhaps it is more obvious when you already know the answer before
reading the text :-)

I don't think that Jonathan expects there to be any upward search
from the interface referenced by the virtual interface.  He is
just pointing out that this is a transition from a select of a
struct member back into selection of design hierarchy.  When Jonathan
says that we are reverting to hierarchical resolution, he means that
we are reverting to resolving to nested static scopes that may include
instance hierarchy.

When Gord hears "start all over again with hierarchical resolution",
he assumes that means doing the thing that is most different about
hierarchical resolution of a path.  That is the upward search at the
beginning of it (and which he apparently assumed until recently could
occur at any point within it).  Because he has paid so much attention
to this aspect, it is the first thing he thinks of when someone says
anything about hierarchical resolution.  But I don't think that this
is what Jonathan is suggesting.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Sep 25 10:17:42 2007

This archive was generated by hypermail 2.1.8 : Tue Sep 25 2007 - 10:17:58 PDT