Summary: I can"t find in the COM/CORBA spec parts A and B any mention of how to
deal with IDL identifiers that are keywords to the Microsoft "mktyplib" tool.
This tool mangles the following identifier (not necessarily a complete list) by
prepending them with "_":

"BSTR", "CALLCONV", "coclass", "CY",
"CURRENCY", "DATE", "DECIMAL", "DISPID", "DISPPARAMS",
"dual", "EXCEPINFO", "guid", "GUID",
"HRESULT", "importlib", "IDispatch",
"INTERFACEDATA", "IUnknown", "LCID",
"METHODDATA", "odl", "oleautomation",
"PARAMDATA", "properties", "propget", "propput", "retval",
"SAFEARRAY", "SAFEARRAYBOUND", "SCODE",
"VARIANT", "VARIANTARG", "VARIANT_BOOL",
"VARTYPE", "VARENUM"

As far as I can tell, the output of the "mktyplib" tool makes use
(directly or indirectly) of the regular C++ bindings, whose identifiers
are not mangled the same way. This makes it impossible to emit COM bindings
for IDL files that contain the above keywords.

The problem that I"m running into is in CosTrading IDL, where the identifier
"properties" is used.

Summary: 2) Attribute "name" in interface ValueMemberDef clashes with attribute "name"
inherited from Contained. A different name should be used, something like
"value_member_name"

Summary: Clarify the hash code algorithm

Summary: It is not clear whether the #pragma prefix is still part
of the repository Id. I think it should be.

Summary: Why is the 64 bit hash code at the end of the string and
not at the beginning ? This can speed up the comparison
when two repository Ids are different.

Summary: 2) How does one find out a RepositoryID for registering a factory or a streaming
policy?

Summary: Section 5.6.3 Hashing Algorithm (and 5.6.2)

• It is not clear whether the hash value is translated
  into ascii or not.

• I assume the result is a long long:

long long hash = sha[1] << 32 + sha[0]

Summary: Clarify the exact semantics of computing the hash code and comparison semantics for type equivlanece. (lost email, paraphrase of issue)

Summary: I have an important issue concerning the C++ mapping and the fact
that application developers need to define/implement the concrete
value class.

Summary: In the Java mapping example on page 6-64 the operations are mapped to
public operations of the Java class. However in the C++ mapping example on page
7-95, the operations are mapped to protected pure virtual functions of the
generated C++ class.

Summary: What is the rationale for making ValueBase a value and not a native type?
It seems strange to me that a ValueBase "value" maps to java.io.serializable
in Java. Isn"t that what native was invented for?

Summary: A typo: on page 8-107, interface Account should inherit ":" from Describable and
value Currency should support Describable.

Summary: 1) Can the "public" modifier be applied to value operations? What is the default?

Summary: There are no typecodes for abstract interfaces. Does this mean
that abstract interfaces cannot be members of structs, unions,
or values? If so, I think this is a problem and we should add
typecodes for abstract interfaces.

Summary: There is a bit of confusion in the specification concerning the
exceptions that are possible during the internalization process.

The internalize operation can raise CosLifeCycle::NoFactory and
StreamDataFormatError exceptions. This operation calls the
internalize_from_stream operation of the Streamable interface that can
raise the CosLifeCycle::NoFactory, StreamDataFormatError, and
ObjectCreationError exceptions.The last paragraph on page 8-20 (August
1997 release) states that the ObjectCreationError and
StreamDataFormatError exceptions of the internalize_from_stream
operation originate from the read_object amd read_<type> operations on
the StreamIO interface. However, the ObjectCreationError is not raised
by any of these, according to the IDL in figure 8-6.

Summary: Circular refrences to CosStream and CosCompoundExternalization,
i have not been able to find an idl compiler that can compile
these modules.

as aside, i have foud many syntax errors in the IDL you provide
as CORBAServices98-03-02.idl, in many of its interfaces, there are
typos, and it is not correct with the specifications.

Summary: in section 4.9.2 last paragraph:

"Such a ProxyPushSupplier is guaranteed only to invoke operations defined in
interface I. Any event on the channel that does not correspond to an
operation defined in interface I is NOT passed on to the consumer. Such a
ProxyPushSupplier is therefore an event filter based on type".

My question is: if we have this proxy to block generic calls (push() in this
case) why does TypedPushConsumer inherit CosEventComm::PushConsumer, whish does
support push() ? Why should the generic calls like push() be blocked anyway
if (according to 4.7.1) TypedPushConsumer should support both typed and generic
models ?

Is there something I am misunderstanding ?

Summary: The submission makes no mention of HTTP tunnelling. There are many
firewalls which filter HTTP, FTP and email related traffic. Is the
omission based on the assumption that such firewalls will comprise
a CORBA conformant GIOP proxy on a well-known IIOP port? The Bi-
directional GIOP specification suggests not (section 5-1,
paragraph 2).

Is tunnelling regarded as an implementation matter? If so there
will be important issues such as relaxing GIOP/HTTP mapping and
security which the specification should clarify.

Summary: The issue comes from the following configuration:

Client - Tcp Firewall - Giop Proxy Server - Server

The server"s IOR will contains a FirewallComponent, which includes two
FirewallMechanisms - a TcpFirewallMechanism and a GIOPProxy. The issue
comes when the GIOP Proxy has multiple profiles, which may have different
host/port, and the TcpFirewallMechanism can only have one host/port. Does
that mean for any host/port specified in one of the GIOP Proxy "s profiles,
you always to connect to the host/port specified in the
TcpFirewallMechanism? This seems unrealistic since the Tcp firewall usually
provide a one-to-one mapping.

Summary: 5. The ValueHelper interface contains the method get_safe_base_ids, which is
inconsistent with current OBV terminology.

Summary: The OBV spec orbos/98-01-18 introduces a new repository ID
mechanism. It says in 5.6.2.1

>> We don"t recommand the classic id format "IDL:" <scoped name> ":"
>> <major> "." <minor> because it is not "foolproof" enough. (It is of
>> course allowable to use this format, since the CORE specification
>> does not mandate any particular form.)

The last sentence is not entirely correct, as 8.6.4 of formal/98-02-33
specifies

>> A definition is globally identified by an OMG IDL - format
>> RepositoryId if no ID pragma is encountered for it.

The issue is whether the OBV specification changes this default for
values or not

Summary: The OBV design for the "CORBA::tk_value" TypeCode defines a
potentially recursive constructed type that involves ValueMembers.
The "tk_value" TypeCode defines the entire complexity of the types
within the Value.

It is our understanding that when the ORB code that handles "Anys" for
C++ detects a tk_value TypeCode and needs to encode/decode the associated
Value object – (e.g., for Any::replace(TypeCode, void *) – it will
need to invoke a method on that object that understands the object
instance data and the associated state information. Further
examination of the TypeCode complexity will not be necessary by the
Any implementation, since this code would not have knowledge of or
ability to set the state information within the Value object itself.

The reason why the layout of the state information within a value
cannot be known by external code is that virtual inheritance of
abstract values and/or abstract interfaces makes it impossible to
calculate the offsets of the data members in a compiler
independent manner.

Summary: Using the IDL defined in Issue # 1352, we have the send() method, in interface Foo, which takes a Base value type as its formal parameter. Now suppose we wish to pass a Derived value type. When marshaling the list of repository ids, the marshaling engine has no notion of the formal type of the parameter, thus it does not know how many safe repository ids it needs to marshal.

Summary: Chapter 5 - Bi-directional GIOP misled me in a number of points, even after
numerous readings and a discussion with an author. I believe the chapter
contains all the pertinent information; it just has to be a bit more
carefully presented.

Summary: The firewall spec defines a number of tag values from OMG managed spaces.
The values of these tags need to be assigned.

Summary: The OBV spec introduces the concept of initializers, which maps
cleanly only to languages that support overloaded constructors.

Other languages, such as C, would typically offer functions to provide
inialization of values. Since initializers are not named, an intuitive
mapping is hard to find.

Summary: The definition for interface CodeBase in module SendingContext
has a method
CORBA::InterfaceRepository get_ir();

There is no type CORBA::InterfaceRepository. I believe this was
intended to say
CORBA::Repository get_ir();

Summary: There are no rules governing how to free value factories in C++.
Specifically, the ORB does not know what to do with the value factory at
shutdown, and applications do not know what to do with the factory
returned by register_value_factory. Directly deleting the factories may
be hazardous (e.g. if they are shared across multiple valuetypes or even
multiple ORBs), and leaving them around may introduce memory leaks.

Summary: Section 5.9.7 of orbos/98-01-18 says that the TypeCode parameters for both
tk_value and tk_value_box start with a string which is the type"s
repository ID. Why? For everything except tk_interface, the repository ID
is not visible as a parameter. I believe these parameter lists should not
include repository IDs to make them consistent with the others.

I assume that the

pairs in the tk_value parameter
list should appear in the order of declaration of the members in the
valuetype. This is not stated anywhere.

The visibility of each member should be added to the tk_value parameter
list. Each entry in the list should contain

where the short refers to the Visibility of the member.

The parameter list for tk_value should probably have an additional
parameter which is the TypeCode of the concrete valuetype base, if any.

Summary: For boxed values that are structs, unions, or other constructed types with
member accessor and modifier functions, their member functions such as
value(), boxed_in(), boxed_inout(), etc. may potentially clash with the
names of those accessor and modifier functions.

Solution: make the names of such special member functions start with an
underscore, e.g., _value(), _boxed_in().

Summary: The custom marshalling streams CDRInputStream and CDROutputStream
don"t support the IDL fixed type. I propose adding the following
type definition and methods:

typedef sequence<fixed> FixedSeq;

abstract value CDROutputStream

;

abstract value CDRInputStream

;

Summary: The OBV spec is not very clear about whether the Java class
generated for an IDL value has a default (no-argument) constructor.

A no-argument constructor is needed so that the Helper class
can construct a value when demarshalling. However, it should be
package-private in order to limit its visbility to the Helper
class and not expose it to client code. This is also true for
state fields declared as private in the IDL value type (which the
spec currently states are mapped to private in Java).

Summary: There"s a problem with the mapping to Java for boxed IDL values
for non-primitive Java types, for example, a boxed string or a
boxed sequence. The currently specified write_Value call doesn"t
allow these to be marshalled correctly.

Summary: The spec does not contain a clear definition of how TypeCodes for
values and value boxes are constructed. There is something about
this in section 5.6.3, but this seems to describe a variant of the
algorithm rather than the algorithm itself. Section 5.9.7 needs to
be expanded to describe this in at least as much detail as the
description of the encoding of recursive sequence TypeCodes in the
current CORBA spec.

Summary: It is not clear from the spec whether or not value boxes can be
forward declared, and used recursively. For example,

value v;
struct s

;
value v s;

If value boxes are indeed syntactic sugar, the answer should be yes.
That brings the next question: Does this mean that one can call
create_box_value_tc(), supplying NULL for the original_type, and
then later on fill in the member typecode via fill_in_recursive_tc,
supplying a ValueMemberSeq of length 1?

Summary: Section 5.8.6 gives the BNF for the GIOP encoding of values but does not
describe the semantics behind them. Some of the semantics are referred
to in earlier section and intuitive for an outsider with a little CORBA
experience. Some of the the explicit semantics seem to be missing
altogether (e.g. the "" in <end_tag>). It would be useful if the
descriptions explicitly used the names within the BNF grammar or
explicit specifications for each name in the grammar was given.

Summary: One of the common patterns used in IDL specifications is to pass a
sequence of a data type in order to cut down on network round trips.
The current OBV spec (orbos/98-01-01) even suggests sending a graph of
objects and optimizing for the case where the same object occurs
multiple times in the graph (which I assume will normally be a small
number of the total objects). The spec seems to be inefficient for
sending a large number of small objects though. I have looked at the
errata before and don"t recall any relavent changes but know the RTF are
considering some now.

Summary: The OBV spec allows a value to support multiple interfaces. In C++, such
values
are specified to derive from the POA skeletons generated from those
interfaces.
This presents a potentially intractable problem: skeletons are not designed to
be inherited together with skeletons for other interfaces because servants do
not support multiple interfaces. (The Multiple Interface RFP isn"t finished
yet, right?) The top of page 20-104 of the latest C++ mapping (orbos/98-05-08)
explicitly says

Summary: 2) In addition to the ValueMemberSeq, the input parameters to
fill_in_recursive_sequence_tc include the target TypeCode
pointer, and the RepositoryId.

What is to be done with the RepositoryId parameter ?
Is the method supposed to update the Id as well ?
If that is the case, is it an optional/required parameter ?

Summary: 1) The fill_in_recursive_sequence_tc method is intended to act
upon an existing "tk_value" TypeCode. The signature indicates
that it should return a TypeCode pointer.

What TypeCode is supposed to be returned ?
If the signature is in error, the specification should
be corrected – if not, the specification requires
some additional explanation as to which TypeCode
needs to be returned.

Summary: The OBV spec defines CDROutputStream and CDRInputStream types values for
custom marshaling. The names of these types should not contain "CDR" since
there is nothing that prevents them from being implemented to use a data
representation other than CDR.

Summary: The OBV spec adds the notion of "chunking" because it claims that "it is
anticipated that value types may be rather large, particularly when a graph
is being transmitted. Hence the encoding supports the breaking up of the
serialization into an arbitrary number of "chunks" in order to facilitate
incremental processing." (orbos/98-01-18, page 5-55)

This "feature" should be removed from the spec, since it is the job of the
underlying transport to handle this issue. GIOP already provides
fragmentation, allowing transports to handle large parameters efficiently
– why should we build yet another fragmentation solution on top of it?

Summary: Can the "public" modifier be applied to value operations? What is the default?
In the Java mapping example on page 6-64 the operations are mapped to
public operations of the Java class. However in the C++ mapping example on page
7-95, the operations are mapped to protected pure virtual functions of the generated
C++ class.

Summary: The "in", "out", and "inout" modifiers on value operation parameters are
effectively comments. This is the case as a value maps to a language
pointer or reference. When it is passed in a local interface
there is no way to guarantee "in" or "out" semantics; it is passed by
reference which essentially has "inout" semantics.

These semantics should be explicitly stated.

Summary: A typo: on page 8-107 of the OBV spec., interface Account should inherit ":" from
Describable and value Currency should support Describable.

Summary: p 5-24, first paragraph of 5.3.1.3:
The implementation of operations may be remote if the value also
supports CORBA.Object.
typo p 5-30, last line of 5.3.2.6: may BE defined

Summary: Given:

abstract interface A {};
interface B : A {};
value C : supports B {};

Can an instance of C be passed by value to an operation that expects an A?

Summary: Semantic of register_value_factory is not clear
What do applications should expect if a factory is already
registered for a given repositoryId?

The operation returns the previous factory. But it is not
clear whether it is overriden or not.

• When should register_factory be called ?
  I assume that this is after the ORB is initialized (since we
  need a pointer to the ORB). This means that initialization
  of "Component Libraries" is not trivial.

Summary: According to the object-by-value C++ mapping, the value type that is
not boxed results in an abstract C++ class. Basically, the reference
counting methods are not provided (abstract). It is the responsibility of
application developer to define/implement a concrete class. Althought
this can be done, there are some issues:

Summary: The default ref-counting classes are said to be "fully concrete".
Is this really necessary?
What is the semantic of "_copy_value" for the ref-counting class?
=> suggest that "_copy_value" MUST NOT be implemented
(It is implemented by "_copy_value" of the real value type)

Summary: - What is the return type of "_add_ref" and "_remove_ref"
(defaults to "int", but what is the semantic of the result value)
=> propose to change to "void"

Summary: TypeCodes:

• It is not clear whether the IDL compiler has to generate
  a TypeCode object for each Value type.

Summary: Missing member_kind and member_tc

Summary: Also, the OBV spec defines a describe_value() operation in interface ValueDef
which returns a FullValueDescription structure. Is there supposed to be another
operation which returns the shorter ValueDescription structure?

Summary: If a value type can inherit from a Boxed Value then what is the implicit name of
the Value Box"s single data member?

Summary: p.6.68: It is a bit awkward that boxed values of "complex" types map
all to the same type (i.e., as for typedefs, the value"s name appears
only in holder/helper classes), and that each boxed value of "basic" type
maps to its individual class. Instead, boxed values of basic types
could map to the corresponding java.lang.* class, e.g.
java.lang.Integer, java.lang.Short, etc. An issue with this approach
is that java.lang.Short and java.lang.Byte are not defined in JDK
1.0.2. I doubt however this JDK is still much in use; for its users,
short and octet could optionally map to e.g. CORBA.ShortValue and
CORBA.ByteValue (inspired from CORBA::StringValue).

Summary: 5.3.3: Is it possible to have a value inherit from (ie, support) a
boxed value ? If yes, the Java mapping of boxed values of type
string, sequence and arrays should be changed because String
and arrays can"t be extended in Java.

Summary: Can a Value type inherit from a Value Box type (the Value Box is described
as been syntactic sugar for a Value type)?

Summary: 1) ValueDefSeq is used in a couple of places but is never defined. A typedef
for it is missing.

Summary:
I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy
issue.

In page 4-45, the spec says "It is possible to support pass-through through
multiple proxies. For example if in the above example there was another
proxy B2 between B and C, during processing the new_target operation from A,
B can try to establish a pass-through connection to C via a call to
new_target on B2. If this fails, due to NO_PERMISSION for example, B should
fall back to try to connect through B2 using the NORMAL mode.".

If the connection (B - B2) is NORMAL, the whole connection is not a
PASSTHROUGH since the client will see the B2"s identity in the SSL session.
Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION
from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is
what spec says), does this mean that it is possible that the client request
a PASSTHROUGH connection but actually get a NORMAL connection?

Summary: 2. The current language mapping mixes both generated code with user
written code in the same source file. This poses a very complex "tool"
issue for IDL compilers which is unnecessarily complex.

Summary: On page 5-44, a new production has been added to the grammar to allow the use of ValueBase to be used as a base type. (<base_type_spec> ::= ... | <value_type_spec). My concern is that all other types of base type specifiers have a PrimitiveKind. However, either you guys forgot or didn"t want to have, that a value or ValueBase does not have a corresponding PrimitiveKind enum value. This becomes essential later on when we want to go into the InterfaceRepository, and find that some type is a ValueBase, we will need to know this. The easiest way to do this could be through a PrimitiveDef, where it"s def_kind attribute is a dk_Primitive, and to satisfy the IDLType interface for they type attribute, we could return a TCKind of tk_value or tk_ValueBase. An alternate could be to not go the PrimitiveDef route and use a different approach. Perhaps we could have a method in the Container or Repository interfaces called create_ValueBase. This would be much like creating an unnamed type such as a sequence, a string, primitive, or array (i.e. get_primitive(), create_string(), etc. in the Repository interface). This is less likely though because create_ValueBase would need to return a type. We could return a ValueDef, but create_ValueBase wouldn"t have enough information passed to it to create on and besides, a ValueDef is named. We could have a whole new definition interface called ValueBaseDef, but this way is a pain if you ask me.

Summary: 1. There are no write_Abstract and read_Abstract methods on
DataInputCtream and DataInputStream. This looks like an oversight
to me.

Summary: It has been pointed out to me that we have no way of narrowing
from abstract interfaces to non-abstract interfaces and value
classes. In Java, the helper"s narrow method has a signature of
org.omg.CORBA.Object, so it cannot take an abstract interface
type. In C++, the generated classes for abstract interfaces
have an _narrow method with the right signature (taking an
AbstractBase_ptr), but generated classes for values and regular
interfaces don"t have such a method. It seems like we would
need to add overloaded narrow methods in all these places to
make this work as envisaged in (for example) numbered paragraph
3 of section 8.3.

Summary: Section 5.3.1.2 says that non-public data members should be mapped
so that "the private part of the state is only accessible to the
implementation code and the marshaling routines."

Section 6.3.1 says that non-public data members are mapped to
private instance variables.

The problem is that the Java marshaling routines are in the Helper
class, which cannot see private instance variables in the value class.

The proposed solution is to modify the Java mapping to map the default
IDL state to the default (package visibility) Java state instead of
private.

Summary: In Section 5.9.1 on p. 5-55 of orbos/98-01-18, the spec says "the sending context is responsible for listing the repository ID"s for all the base types to which it is safe to truncate the real
type, going up (the derivation hierarchy) to, and including if appropriate the formal type". Currently, there is no portable way to obtain the list of type safe repository ID"s
from within the marshaling engine in order to be marshaled on-the-wire properly.

Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications. It specifies that a keyword identifier
is a word that is treated as a keyword only when used in a keyword
context, and is otherwise treated as a regular identifier.
4) Finally, the keyword identifier approach gives the impression that
IDL extensions can be made at no cost, which is simply not true.

Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications. It specifies that a keyword identifier
is a word that is treated as a keyword only when used in a keyword
context, and is otherwise treated as a regular identifier.
3) It allows IDL specifications that, while not unparseable, are
highly ambiguous, especially to a human reader. For example, Jeff
recently posted answers on how the following is to be parsed, but
there is no way that someone reading the OBV spec would be able to
figure out the rules he gave:

interface public

;
value safe

; // Is this legal or an error?
value foo2 : safe safe

; // What about this?
value foo3

;

While all of these constructs can all be parsed using the appropriate
number of look-ahead tokens (by the way, the grammar is not LALR(1)
as the OBV Spec suggests), it is hard to read and even harder to
parse correctly. Many IDL compilers still fail to properly implement
the name lookup rules in the existing CORBA specification, and adding
keyword identifiers will only make that situation much worse.

Summary:
The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications.It allows IDL specifications that are simply unparseable. For example:

interface ValueBase {};
struct S

;

This is ambiguous because the compiler cannot know whether the type
of struct member "v" refers to the ValueBase interface or the
ValueBase keyword identifier.

Summary:
The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications.
1) First and foremost, the addition of keyword identifiers changes
the IDL grammar into a context-sensitive grammar, which are known to
be notoriously difficult to parse.

Summary: Reconcile RMI/IIOP upcall and helper class

Summary: p 5-50, 2nd paragraph of 5.6.2.1: it seems to me that in existing
ORBs, version inconsistencies between, eg, structs, may already corrupt
memory. The difference now is that preservation of values sharing
could make matters worse. It would be great to have this issue better
explained.

Summary: typo p 5-50, first paragraph of 5.6.2.1: *s*IDL compilerS keep on spitting...

Summary: Suggested changes (to section 5.4.1 of orbos/98-01-18) are:

1. Remove the ``;"" from the end of the definition of <value>. (It"s
in the modified <definition>.)

2. Remove [ <supports_token> <scoped_name>

* ]
from the <value_inheritance_spec> non-terminal move it to a new
non-terminal, <value_supports_spec>.

3. Change the definitions of <value_abs_dcl> and <value_header>,
replacing [ <value_inheritance_spec> ] by [ <value_inheritance
_spec ] [ <value_supports_spec> ].

Summary: Section 5.4.2 "New lexical type - Keyword Identifier" the statement is made that
"new keyword identifiers should only be added such that the resulting grammar is
still easily parsable, e.g. is LALR(1).". It seems to me that is not true even for
the newly introduced keyword identifiers in many cases.

Summary: Above rules seem to imply that the
"safe" keyword identifier can only occur before the first scoped name in the
<value_parent_spec>, whereas I think the actual intent is that it can only
occur before a non-abstract value type, of which there is at most one in the
list, although it need not be the first. Since this can"t be expressed in the
rules exactly, I would simply amend the rule to be:

<value_parent_spec> ::= ":" [ <safe_token> ] <scoped_name>

*

and simply express the semantic restriction in the text. There already is a
brief mention of the semantics of the "safe" keyword in section 5.3.2.5
"Substitutability Issues". Perhaps another sentence or two would help clarify
the intended usage.

Summary: The OBV spec (orbos/98-01-18) does not specify which TypeCode operations apply
to Value and ValueBox types. For example, are id(), name(), member_name(),
member_count(), member_type(), etc. valid for Value and ValueBox or should they
raise BadKind exception?

I don"t see why they should not be valid. Normative text should be added in
CORBA 2.2 section 8.7.1 TypeCode Interface to reflect this and the comments in
the IDL should also be updated.

Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is
described as been syntactic sugar for a Value type)? If so, what is the
implicit name of the Value Box"s single data member?