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

Steven,  I basically agree with what you've said below.  I
definitely agree that there is some conceptual alignment of
the parent class initializers and the use of "this".

I haven't previously stated a position on initializers of
parent classes, so here it is.  I think that the "correct"
order is (in deepest first order):
   1) base class initializers
   2) base class constructor
   3) current class initializers
   4) current class constructor

This aligns with the view you mention (below) that initializers
are (in a sense) part of the constructor and run after the
super.new.

Given that, I agree with the philosophical point that the use
of "this" in an initializer isn't a problem when used as
a value.  When used as a select prefix, I agree that there are
issues and we might want to restrict that both as part of
an initializer and prior to super.new.


So, as I indicated, I wouldn't have any problem with both
allowing "this" as an initializer and the more general relaxation
of using previous formals as defaults in a tf declaration.

While I agree with your intent, I don't think that all
participants have/had the same intent.  Since I don't think there
is consensus on these approaches, it is likely that there will
continue to be divergence and that this will be a fairly
serious issue to resolve in the next PAR.

Gord.

Steven Sharp wrote:
>> 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
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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