Language Change Specification for Composition with Protected Types

Revision Notes

• Changes variable to private variable
• Updated most paragraphs to reflect this.
• Added section on elaboration to clarify which object is locked when calling an object via an alias.

Comments

Variables should not be exposed on a public interface. The better way to allow externally visible nesting is a function returning an access type to the inner protected type. Other languages call this a getter or read-only property.

-- Patrick Lehmann - 2017-01-25

@PL: The heart of this proposal is to allow variables of a protected type in the declarative region of another protected type. Then to allow aliases to the methods of the variables of the protected type. This is accomplished by the BNF and the restriction P58 that requires the variable to have a protected type.

Note that in VHDL sequential code, such as a protected type body, process, or subprogram body, protected typed objects are referenced by regular variables and not shared variables.

-- Jim Lewis - 2017-01-26

@Patrick, Lieven, and Hendrik, First note, the variable made visible is not a regular variable it is a protected type.

Next, what this does is create a public variable of a protected type - something that many other class based languages allow.

Next, the alternative is brutal. One must manually create the layering by putting a variable in the protected type body and creating accessor functions. Which in VHDL means creating the declaration and the body.

-- Jim Lewis - 2017-01-27

@Jim From a software standpoint it's no good idea to have public variables. Languages that expose public variables are mostly transforming them into invisible getter methods. I'll need some days to think about your goals, what other languages do or could offer and how it fit's into the VHDL concept. So please understand my vote as "put on hold" but not as a 100% down vote. Your proposed use case also touches the concepts of inheritance and multiple inheritance (mix-ins) with renaming. I just want to make sure for my self, that we don't make false design decisions as done for shared variables and protected types in 2002...

-- Patrick Lehmann - 2017-01-27

@PL To have a good technical discussion, you need to provide more details about the issues you are trying to illuminate. From what I found, the issue has to do with issues if the reference PT changes - either methods or parameter names on the methods - could potentially break the usage.

I have some thoughts about making the variable private (not too difficult) and creating a shorthand subprogram that provides its own parameter names rather than using the name of the referenced object like an alias does. Not sure I will get them developed on time for this revision though.

-- Jim Lewis - 2017-01-29

@Jim: Having public variables is ok, but such variables will not be part of the shared data of the protected type as defined in clause 5.6.1 because exclusive access cannot be guaranteed for these public shared variables. For example, if you have:

type PT is protected
  shared variable v1 : some_PT1;
  shared variable v2 : some_PT2;
  procedure p;
end protected;

-- body declaration

shared variable sv : PT;

One process can call a method on sv.v1, wheres another one can call a method on sv.v2, and a third one can call a method on sv --- all at the same time!

Is this what you want?

-- Martin Zabel - 2017-01-29

@MZ No. That would be bad as there can be dependencies that result in deadlock. If the prefix contains sv, we can restrict it in the same way that calls to methods are restricted. In addition, we would need to forbid the creation of pointers to sv.v1 and sv.v2 - ie if 014b comes to fruition, then we need to disallow it here.

-- Jim Lewis - 2017-01-31

@MZ Reflecting on your example, it is safe to call sv.v1.a1 and sv.v2.b1 simultaneously since they are independent objects. However, the method p may also call a method of v1 or v2. As a result, if a method of sv.v1 is called, it must lock sv in order to prevent calls to method p.

This all becomes a mute point with version 2 since the variable are no longer visible - only aliases to methods within the variables are visible. Hence, there is no longer a sense of independent variables - and perhaps that is exactly how it should be.

-- Jim Lewis - 2017-02-11

Updated to revision 2. Variables are now private and required to be labeled as such.

-- Jim Lewis - 2017-02-11

I think the following sentence should be more specific:
An alias declaration in a protected type declarative region may make a method of the private variable holding a protected type instance visible.

Should this sentence:
It is an error if an alias defined inside of the protected type denotes anything other than a method of a protected type.
be in the alias section? -- Patrick Lehmann - 2017-02-16