Hi Satyender,
here is a (probably incomplete) list of things validation should
check
- all kinds of
usercode: no access to instance data (attributes/operations)
of the class
- scope of local
variables: no usage before declaration, no visibility outside
enclosing block
- arithmetic
operations only with primitive types
- no assignment of
primitive type to complex type and vice versa
- port.msg() is like
call to void operation, not allowed in arithmetic expressions
- the type of a GVar
has to be a DataType or a GaclTypeDecl (I would propose this
is done by scoping)
You should definitely
try content assist in different places and see which items
should be ruled out by scoping or by validation.
It just comes to my
mind that we didn't think about support for concepts of value as
opposed to reference.
In ROOM we use the keyword 'ref'. Variables, attributes, return
types and operation parameters can be declared as ref.
I think that the GVarDecl should be extended by a similar
concept, e.g.
GVarDecl:
{GVarDecl} 'var' name=ID (':' td=[SingularDecl])?
(ref?='ref')? ('[' idx+=INT ']')*';'
;
Additionally we should have operators that turn references into
values and vice versa. In C we have * and & resp.
I would propose a function-like notation in the style (if the
prefix is simpler we can use the C notation):
var x: int32;
var p: int32 ref;
x = val(p); // corresponds to x = *p
p = ref(x); // corresponds to p = &x
A problem is that Java doesn't support this.
In Java we currently support message data to be a ref with the
semantics that the object itself is passed with the message
rather than a deep copy.
So maybe the solution will be that the specific language
generator issues an error if this concept is used but not
supported.
@eTrice developers: do
you have any suggestions on how to cope with references?
-Henrik
--
______________________________
Dr. Henrik Rentz-Reichert
mailto:hrr@xxxxxxxxx
+49-7551-831365
Am Bacheck 7A
D-88662 Überlingen-Deisendorf
