Subject: Re: [sv-ec] class scope resolution operator
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Thu Mar 13 2003 - 11:49:25 PST
Jay,
There are several reasons to keep the two operators separate.
The nesting of classes and modules is different, and the '::' operator
behaves differently from '.'. The class scope is available to the '::'
without having to instantiate the class, only the declaration.
The '::' operator can import a type from within the class scope (this
is one of the most important capabilities of '::'). The '.' is currently
not able to import types, only instantiated objects. Allowing '.' to
import types creates separate compilation problems.
The '.' operator has very different search semantics. It allows
searching from the root of the design down, whereas '::' is strictly
a local operator (local from the current module, interface, program).
The key point is that class type hierarchy is different from structural
hierarchy, and different from functional hierarchy (class derivation),
and it's helpful to keep the concepts separate.
The '::' operator is already used to declare out-of-body methods,
and using '.' in that context is a stretch since it is actually adding
an implementation into a scope (a class scope, that is).
Finally, classes already overload the '.' operator to mean member
selection (dereference or method call). Neither Java nor C++ do
overload the '.' operator in this fashion, so this helps keep the class
extension consistent with other mainstream languages.
Arturo
----- Original Message -----
From: "Jay Lawrence" <lawrence@cadence.com>
To: "Arturo Salz" <Arturo.Salz@synopsys.COM>; <sv-ec@eda.org>
Cc: "David W. Smith" <david.smith@synopsys.COM>
Sent: Thursday, March 13, 2003 5:16 AM
Subject: RE: [sv-ec] class scope resolution operator
Arturo,
This is a good addition to specify how to get at the static things in
classes, but why is the class scope operator '::' different from just a
regular hierarchical reference to an element in a class via '.'?
This document says "Like modules, classes are scopes and can nest". If
they are scopes like modules then we should just allow the regular XMR
syntax.
Jay
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Wednesday, March 12, 2003 6:20 AM
> To: sv-ec@eda.org
> Cc: David W. Smith
> Subject: [sv-ec] class scope resolution operator
>
>
> Greetings,
>
> Attached is the proposal for the class scope resolution
> operator :: (AI-56)
>
> Arturo
>
>
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 11:47:52 PST