RFR:JDK-8198749 Translation of value constructors in classic constructor notation (original) (raw)
John Rose john.r.rose at oracle.com
Thu Jul 12 17:54:09 UTC 2018
- Previous message (by thread): RFR:JDK-8198749 Translation of value constructors in classic constructor notation
- Next message (by thread): RFR:JDK-8198749 Translation of value constructors in classic constructor notation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Jul 12, 2018, at 12:45 AM, Remi Forax <forax at univ-mlv.fr> wrote:
I will prefer not too allow (value) class constructor to return a value, it's what factory method are for. I think it's better to: - allow factory method for value and reference that returns a value/reference of any type. - have value class constructor automatically translated to factory method by the compiler. - make constructor and factory mutually exclusive.
All that is reasonable to me. (Scoping is after LW1 of course.)
So you vote for making a clean break from to . That's probably the right thing to do; I can't think of a strong reason to cleverly recycle (with a new method type) to denote .
My point about an early value-return makes sense for but not , since is required to update its given L[0] argument in place.
In the language, I'm speculating that there could be a place for a kind of source-level constructor which is really a method not an method. That kind of constructor could logically be given the capability to do an early value-return, since it's really a factory method.
Such a constructor, if we decided to create it, would need a method type signature which allowed the value-return. Value types always have this, while currently object types never have this signature. So there's a notation problem to solve, which I don't have much opinion on. Maybe you mark a constructor using the keyword "factory" in an object class, and constructors in value classes are always factories?
It's almost possible to make and mutually exclusive, except for non-final objects. In that case, the object class has API points for creators, which should be named , and API points for subclasses, which still need to be named .
In a case like that, the method, if it is derived from a non-factory constructor, consists of the following code:
ACC_STATIC (Arg…)ObjCls { new ObjCls dup push Arg... invokespecial ObjCls.(Arg…)V areturn }
The method can be downgraded from ACC_PUBLIC to ACC_PROTECTED, and the verifier can be tightened up to exclude uses of which are now covered by .
Result: A new convention for canonical factory methods for all types (object, value, interface), replacing and extending the translation strategy that used for "new ObjClass(arg…)".
— John
- Previous message (by thread): RFR:JDK-8198749 Translation of value constructors in classic constructor notation
- Next message (by thread): RFR:JDK-8198749 Translation of value constructors in classic constructor notation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]