id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5580	--evaluateProtectedParameters should default to true	Francesco Casella	Karim Adbdelhak	"I scanned the specification looking for the various meanings of {{{protected}}}, trying to understand how should we deal with {{{protected}}} parameters. 

In particular, Section 4.1 states:
  A protected element, P, in classes and components may not be accessed via dot notation (e.g., A.P, a.P, a[1].P, a.b.P, .A.P; but there is no restriction on using P or P.x for a protected element P). They may not be modified or redeclared except for modifiers applied to protected elements in a base-class modification (not inside any component or class) and the modifier on the declaration of the protected element.

As far as {{{final}}} is concerned, Section 7.2.6 states 
  An element defined as final by the final prefix in an element modification or declaration cannot be modified by a modification or by a redeclaration

We all agree that the interpretation of {{{final}}} can be extended to mean that you can't change the parameter value ''at runtime''. What I understand from the two excerpts of the specifications is that from this point of view there is no difference between a {{{final}}} parameter and a {{{protected}}} parameter: both cannot be modified. Redeclarations do not apply at runtime, because we are using statically compiled models,so they are ruled out anyway.

Conclusion:
- there is no reason to treat {{{protected}}} parameters differently from {{{final}}} parameters
- {{{--evaluateProtectedParameters}}} should default to {{{true}}}."	defect	new	high		Backend