Re: [sv-ec] Where can you use "this"?

>I don't believe that you can use "this" to initialize class properties
>other than within the constructor.  So the example you have would not
>be legal in the current LRM.

By the literal wording, I think you are correct.  A class property
initializer is not inside a non-static method.

However, it may make sense to allow it.  I think it depends on the
resolution of Daniel's question of when the initializer is executed
relative to the user-defined new() function, and the super.new()
call inside it.

If the initializer is executed in the new() function after the
super.new() is executed, then there is no reason you should not be
able to use 'this' in the initializers.  They are implicitly inside
a non-static method and 'this' is well-defined.  If you execute them
in source order, all properties that can be referenced will already
have been initialized.

If the initializer is executed before the new() is called, then it
is not inside a non-static method.  If it is executed inside the
new(), but not before the super.new(), then the base class has not
been initialized yet.  Either way, a reference to 'this' should not
be allowed.  Note that this applies to implicit references to 'this'
also, so an initializer could not refer to another non-static class
property either.

As I have said previously, I think the LRM says that the initializers
are executed after the super.new().  If so, then there is no reason to
disallow references to 'this' in the initializers.


>This question relates indirectly to other discussions related to
>defaults of methods.  For example, can you have something like
>the following:
>    function void new (MyType me = this);
>    endfuncion
>
>I'd like the answer to be consistent with the answer to the legality of
>the following:
>    function void new (int a = 1, int b = a);
>    endfuncion

Here I think we should separate the behavior of 'new' from the
behavior of other tasks and functions.

In general, I think users would like to be able to refer to earlier
formals in an argument default.  Within a method, I think they would
like to be able to refer to 'this', or to a nonstatic property using
an explicit or implicit reference to 'this'.

This is an issue of the scope where the default value is resolved.
The LRM says that they are resolved in the scope where the task/function
is declared.  However, I believe this text was intended to make clear
that they were NOT resolved in the scope of the task/function call.  I
don't think the exact scope around the declaration was really considered
in writing this text.  Given the greater usefulness of resolving them
inside the scope of the task/function at the lexical point of reference,
I think that is a better answer.

Now back to 'new': I have already commented on the hole that is
created by being able to refer to uninitialized base-class or derived-
class properties in the actual arguments to an explicit super.new()
call.  Daniel has also pointed out another potential hole created by
being able to refer to them in initializers on variables declared in
the scope of 'new'.  The default value for an argument of 'new' would
be yet another hole.  In your example, you only refer to 'this' itself,
which is not a problem.  But if that is allowed, there is nothing to
prevent making a reference to a property through 'this'.

I think that these holes should be plugged.  I think Dave Rich agreed
that it should be illegal to refer to 'this' or 'super' before the
super.new() call.


>My view (reflected indirectly by the LRM) is that "this" behaves like
>an implicit formal to all non-static methods which is why you
>can't use it for an initialization expression.  The use of "this" as
>even a default would then be related to the question of using other
>formals in default expressions.

I agree that these are related, and should have the same answer.

>The point has been made in the past that the current LRM requires that
>defaults be resolved in the context of the scope containing the
>routine so I think that current LRM wording would most consistently
>be treated as disallowing the use of "this" even as the default
>of task/function formal.

I agree that the text says this.  I don't know that anyone deliberately
decided it should be this scope rather than inside the scope of the
task/function.  If the intent of the text is taken as just distinguishing
between resolution at the caller versus the callee, and the normal
lexical scoping rules are followed at the position of the caller, then
it would not be a great stretch to get the other interpretation.


>I would not be opposed to relaxing the rules for defaults nor would I
>be opposed to allowing "this" as an initializer for a non-static property.
>But I do think that the current LRM disallows both and that such a
>change would have to be in the next PAR.

I think a case could be made for both being interpretations of the intent
of the existing text.  I don't think it is a strong case, but if users
think this is the most useful interpretation, I could support it.

In the case of the defaults, I think we would want to plug the hole in
referring to uninitialized properties in new().  In the case of initializers,
I think this would have to be linked to the decision about when the
initializers are executed relative to new() and super.new().

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.