Hi Brian,
Nice sump-up, i like it very much.
I believe we also need to think about type parameters, they are also impacted
by the nesting/static context so should be in NC(X).
Rémi
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mardi 7 Janvier 2020 21:30:27
> Objet: Towards
We have introduce records because it's a simple abstraction to extract values
when doing the pattern matching.
Given that records are named tuples, does it means that a deconstructor is just
a classical method with no parameter and a record as return type ?
public class Point {
private final
Now that the design of Record is mostly stabilized, i think we should talk
about the relation between an enum, a record and a sealed type.
As we have done with records, we can work backward from the pattern matching
switch to see what we need for an enum.
So let suppose that like Java2D, we
Yes, i agree.
Rémi
> De: "Brian Goetz"
> À: "Tagir Valeev" , "amber-spec-experts"
>
> Envoyé: Dimanche 29 Décembre 2019 18:35:08
> Objet: Re: [records] SafeVarargs and canonical constructors
> This seems a very practical place to land here.
> On 12/29/2019 12:32 PM, Tagir Valeev wrote:
>>
yes, this code should not compile, a local record should not be able to capture
local variables.
An "inner" record is implicitly static for the same reason.
Rémi
> De: "Maurizio Cimadamore"
> À: "Vicente Romero" , "compiler-dev"
>
> Envoyé: Jeudi 12 Décembre 2019 13:34:38
> Objet: Re: RFR:
oops, link to the wrong proposal
https://github.com/dotnet/csharplang/blob/master/proposals/records.md
Rémi
- Mail original -
> De: "Remi Forax"
> À: "amber-spec-experts"
> Envoyé: Vendredi 6 Décembre 2019 12:05:13
> Objet: Record in C# 9 (proposal)
&g
Record from Vancouver :)
https://github.com/dotnet/csharplang/blob/master/proposals/recordsv2.md
Rémi
Hi Chris,
Please do not add another java.io.File.listFiles() !
People will test a code that use Class.getRecordComponents() only with records
forgetting as usual to have negative tests and it will blow in production.
A method that returns an array should never return null.
I repeat
A method
- Mail original -
> De: "Gavin Bierman"
> À: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Envoyé: Lundi 2 Décembre 2019 13:18:43
> Objet: Re: Pattern variable and field shadowing
> Hi Tagir,
>
> No, that’s very much the expected behaviour. The idea of flow scoping is that
> a
>
- Mail original -
> De: "Tagir Valeev"
> À: "amber-spec-experts"
> Envoyé: Mardi 26 Novembre 2019 09:12:24
> Objet: Evolution of records spec
> Hello!
>
> The current spec draft [1] tells nothing about the possibility to
> migrate an existing class to the record or vice versa. I
It occurs to me that given that record is a new construct, we can fix an error
from the past [1], final field not really be final.
Obviouly, it means that refactoring a class to a record or vice-versa will not
be 100% compatible, but given that we have already introduced Class.isRecord(),
it's
Currently the JVMS spec for record doesn't allow a record component to be
deprecated.
The are several languages, some that run on the JVM like Kotlin or Scala that
have a similar concept of record components and for all of them they allow to
deprecate it,
it should be a no brainer to allow a
I know we already discuss that but i still don't understand why a canonical
constructor has to be public.
I understand that a canonical constructor is not a simple constructor because
it is also used as a kind of default de-constructor, but this doesn't work well
with the current rules for
>> De: "Gavin Bierman"
>> À: "amber-spec-experts" , "amber-dev"
>>
>> Envoyé: Jeudi 31 Octobre 2019 15:17:34
>> Objet: Updated Draft specs for JEP 359 (Records)
>> An updated draft language spec for JEP 359 (Records) is available at:
>> [
>>
> De: "Gavin Bierman"
> À: "amber-spec-experts" , "amber-dev"
>
> Envoyé: Jeudi 31 Octobre 2019 15:17:34
> Objet: Updated Draft specs for JEP 359 (Records)
> An updated draft language spec for JEP 359 (Records) is available at:
> [
>
> De: "Chris Hegarty"
> À: "Vicente Romero"
> Cc: "amber-spec-experts"
> Envoyé: Jeudi 31 Octobre 2019 13:25:53
> Objet: Re: forbidding serialization methods as members of records
>> On 31 Oct 2019, at 12:21, Vicente Romero < [
>> mailto:vicente.rom...@oracle.com |
>>
groups) because the inability to express a raw string in Java.
>
>> On Oct 30, 2019, at 9:13 AM, Remi Forax wrote:
>>
>>
>>
>> On October 30, 2019 12:30:06 PM UTC, Brian Goetz
>mailto:brian.go...@oracle.com>> wrote:
>>> First of all, the two
14.30.3 is weird to me, why use the cast operation that doesn't raise an
exception instead of instanceof granting the null case is handled before ?
Rémi
> De: "Gavin Bierman"
> À: "amber-spec-experts"
> Cc: "amber-dev"
> Envoyé: Lundi 21 Octobre 2019 11:50:11
> Objet: Draft JLS spec for
Tagir,
there is an easy way to create a nonegleton, use a sealed interface with one
implementation class and then remove that class :)
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 18 Octobre 2019 16:16:54
> Objet: Re:
It seems we have to add an access_flag for each record component because we
have to mark if the record component is a varargs or not.
So the format should be
Record_attribute {
u2 attribute_name_index;
u4 attribute_length;
u2 number_of_record_components;
{ u2 component_access_flags;
Hi Johnathan,
as others said, i find the javadoc very clear.
Minor nits, for equals:
"Indicates whether some other object is "equal to" this one. The objects are
equal if the other object is of the same class and if all the record components
are equal. All components are compared with '=='."
- Mail original -
> De: "Maurizio Cimadamore"
> À: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 11 Octobre 2019 12:59:41
> Objet: Re: [sealed] Sealed local classes?
> I think an enum declaration is 'morally final' in the sense that, while
> it can't really be marked
switch to amber-spec-experts, because it's about the binary representation of a
Record in the classfile.
- Mail original -
> De: "Maurizio Cimadamore"
> À: "Harold David Seigel" , "amber-dev"
>
> Envoyé: Jeudi 10 Octobre 2019 22:03:23
> Objet: Re: Class.getRecordComponent() javadoc
mandated structures, including the values methods on enum types, etc.
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>> On 10/10/2019 8:50 AM, Brian Goetz wrote:
>>>> We should match the behavior of methods like `Enum::values`.
>>>>
>>>>> On Oct 10, 2019, at 10:15 AM, Remi Forax wrote:
>>>>>
>>>>> Hi all,
>>>>> fields and methods of a record are marked ACC_MANDATED which contradict
>>>>> JLS
>>>>> 13.1.12 that explains that you can not use ACC_MANDATED on field and
>>>>> method.
>>>>>
>>>>> regards,
>>>>> Rémi
>>>>>
Hi all,
fields and methods of a record are marked ACC_MANDATED which contradict JLS
13.1.12 that explains that you can not use ACC_MANDATED on field and method.
regards,
Rémi
Hi all,
ASM doesn't like too much weird method names,
exactly the ASMifier, that take a binary class and generate the Java code that
will create the same binary class, doesn't work well with the method named
"\%pattern\%RecordSubType\%(ILjava\|lang\|String\?)".
I have two questions:
- why do we
I agree, PermittedSubtypes should only contain stable names :)
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mercredi 9 Octobre 2019 23:35:48
> Objet: Re: [sealed] Sealed local classes?
>> Proposal: ban `sealed` and `non-sealed` modifiers on _local_
I agree, PermittedSubtypes should only contains stable names.
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mercredi 9 Octobre 2019 23:26:26
> Objet: [sealed] Sealed local classes?
> It is allowable, though somewhat silly, to put the `final` modifier
- Mail original -
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mercredi 9 Octobre 2019 23:10:40
> Objet: [records] Native members
> Jon has pointed out that it is possible to declare a record with native
> methods and/or constructor.
>
> Let's just add `native` to the set of
- Mail original -
> De: "Remi Forax"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Mercredi 9 Octobre 2019 18:44:23
> Objet: Re: Record Component attributes
> - Mail original -
>> De: "Brian Goetz"
&
Hi all,
just to be sure, do we agree that a record component can be deprecated,
synthetic, have a generic signature, have unknown attributes, have annotation
and type annotations ?
so the attributes with a special meaning are
SIGNATURE, DEPRECATED, SYNTHETIC, RUNTIME_VISIBLE_ANNOTATIONS,
Hi all,
currently a sealed interface is abstract and final,
after having updated ASM to read sealed class/attribute, i try to test it with
some sealed types running some bytecode rewriters of mine, and it was ugly.
2 of them flatly don't work on sealed types, because there are written with the
- Mail original -
> De: "Brian Goetz"
> À: "Peter Levart"
> Cc: "amber-spec-experts"
> Envoyé: Dimanche 6 Octobre 2019 17:06:14
> Objet: Re: Draft JLS spec for records - local types
>> When reading the spec, the following caught my attention:
>>
>> """A nested record type is
Hi everyone,
i'm implementing the support of record (and sealed types) in ASM as an
experimental (preview if you prefer) feature of the future ASM8.
The JEP 359 [1], doesn't include the bytecode format of the Record attribute,
is there a reason ?
Rémi
[1] https://openjdk.java.net/jeps/359
I believe we should allow ourselves to add C in the future,
so Baseline + A + B + any subtypes of a sealed types using the permit clause
implicitly should be explicitly declared final, sealed or non-sealed.
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "Gavin Bierman" ,
- Mail original -
> De: "Brian Goetz"
> À: "Vicente Romero" , "John Rose"
>
> Cc: "amber-spec-experts"
> Envoyé: Mercredi 25 Septembre 2019 16:40:31
> Objet: Re: record components as a first class reflection element
> I think what John is saying is that once we have a reflective
- Mail original -
> De: "Vicente Romero"
> À: "John Rose"
> Cc: "amber-spec-experts"
> Envoyé: Mercredi 25 Septembre 2019 16:15:22
> Objet: Re: record components as a first class reflection element
> On 9/24/19 8:38 PM, John Rose wrote:
>> On Sep 24, 2019, at 1:47 PM, Vicente Romero
De: "Gavin Bierman"
À: "amber-spec-experts"
Envoyé: Jeudi 19 Septembre 2019 11:28:42
Objet: Draft JLS spec for JEP 305: Pattern matching for instanceof
BQ_BEGIN
A draft language spec for JEP 305 (Pattern Matching for instanceof) is
available at:
[
I don't remember if we have discuss this or not but if i read the spec
correctly,
there is no support for the operator ?:
so a code like this is ok
if (o instanceof String s) {
return s.length();
} else {
return 0;
}
while a code like this is not
return (o instanceof String s)?
Hi all,
iwas fianlly enable to have the time to read the spec, yay !
In section 8.10.3::
- what if the record implements an interface with a default method that
provides an implementation for a getter. Currently this implementation is
ignored but i don't know if it's surprising or not. Maybe
- Mail original -
> De: "Brian Goetz"
> À: "Alex Buckley" , "amber-spec-experts"
>
> Envoyé: Mardi 20 Août 2019 00:22:35
> Objet: Re: Refinements for sealed types
>> To be clear, infer `final` on A. We were already inferring `sealed`
>> last week; the new thing this week is to infer
- Mail original -
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Samedi 17 Août 2019 16:24:18
> Objet: Re: Refinements for sealed types
> Since I got a few questions on this, let me step back a bit further and
> shed some light on these requirements.
>
> Sealed types are
- Mail original -
> De: "Brian Goetz"
> À: "Alex Buckley" , "amber-spec-experts"
>
> Envoyé: Jeudi 15 Août 2019 22:02:35
> Objet: Re: Refinements for sealed types
>> So, A is implicitly sealed, but (IIRC) its lack of `permits` means
>> that any class which is in the same compilation
Hi all,
why Record is a class (an abstract class) and not an interface ?
It's not like j.l.Enum which has two fields and several method implementations,
Record just strengthen the contract of Object like a Set strengthen the
contract of Collection, so it seems more like an interface to me.
Hi Brian,
- Mail original -
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mardi 23 Juillet 2019 20:32:08
> Objet: Records: migration compatibility
> In the course of exploring serialization support for records, Chris
> asked about the compatible evolution modes for records.
- Mail original -
> De: "Brian Goetz"
> À: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Envoyé: Jeudi 20 Juin 2019 15:43:46
> Objet: Re: Different serialization strategies for different formats?
> Yes, a similar question came up in an internal discussion as well.
>
>> Consider we have
- Mail original -
> De: "Alan Malloy"
> À: "amber-spec-experts"
> Envoyé: Mardi 4 Juin 2019 00:19:10
> Objet: Revisiting field references
Hi Alan,
i'm sorry but i've more questions than answers,
> Hello, amber-spec-experts. I understand that "field references" is an
> idea that was
yes,
i fully agree.
Rémi
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Mercredi 22 Mai 2019 18:12:03
> Objet: Re: Yield as contextual keyword (was: Call for bikeshed -- break
> replacement in expression switch)
> On May 22, 2019, at 8:45
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Lundi 20 Mai 2019 22:00:43
> Objet: Re: Yield as contextual keyword (was: Call for bikeshed -- break
> replacement in expression switch)
> On May 20, 2019, at 12:51 PM, Brian Goetz wrote:
>>
hyphenated contextual keyword `yield-value` would
> still require careful reasoning about context, about as much as we're
> doing to recognize a unitary contextual keyword `yield`.
>
> Alex
>
> On 5/17/2019 8:40 AM, Remi Forax wrote:
>> Hi Manoj,
>> yield-value
Thanks for providing a clear view of our options.
I vote for B.
I will add that obviously there is no switchy block that contains an
unqualified yield in the actual code so the compiler should emit an error
instead of a warning if there is an unqualified yield in the scope of the
switchy
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 17 Mai 2019 08:41:20
> Objet: Re: Call for bikeshed -- break replacement in expression switch
> (Going back to the start of this thread.)
>
> On May 12, 2019, at 12:38 PM, Brian Goetz
- Mail original -
> De: "Guy Steele"
> À: "Maurizio Cimadamore"
> Cc: "amber-spec-experts" , "Éamonn
> McManus"
> Envoyé: Jeudi 16 Mai 2019 23:41:05
> Objet: Re: Call for bikeshed -- break replacement in expression switch
>> On May 16, 2019, at 5:05 PM, Maurizio Cimadamore
>> wrote:
- Mail original -
> De: "John Rose"
> À: "Alex Buckley"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 17 Mai 2019 03:15:36
> Objet: Re: Call for bikeshed -- break replacement in expression switch
> On May 16, 2019, at 2:43 PM, Alex Buckley wrote:
>>
>> If you're proposing to
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Dimanche 12 Mai 2019 21:38:38
> Objet: Call for bikeshed -- break replacement in expression switch
> As mentioned in the preview mail, we have one more decision to make: the new
> spelling of “break value” in expression switches. We have
> De: "Brian Goetz"
> À: "Alan Malloy"
> Cc: "amber-spec-experts"
> Envoyé: Lundi 29 Avril 2019 23:01:17
> Objet: Re: Feedback on Sealed Types
> It would be nice if we could "just" overload enum itself to support a
> record-like option:
> enum Node {
> AddNode(Node a, Node b),
> MulNode(Node
After a hacking session, i've got your API and nice performance.
[
https://github.com/forax/exotic/blob/master/src/test/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupportExampleTests.java#L12
|
I think there is a merit to separate the primary constructor feature from other
features of a record.
This afternoon while fixing a bug, i took a look to the classes around to see
if it was possible to transform them to records. But i've found that in more
than half of the cases, the classes
I've re-read the current state of the record (ex datum)
http://cr.openjdk.java.net/~briangoetz/amber/datum.html
trying to explain to myself how it works.
At the end of section "Why not "just" do tuples ?", you have this gem,
"A good starting point for thinking about records is that they are
It's more or less the javadoc approach no ?
Rémi
> De: "Guy Steele"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Mercredi 10 Avril 2019 23:36:34
> Objet: Re: String reboot - (1a) incidental whitespace
>> On Apr 10, 2019, at 4:54 PM, Brian Goetz < [ mailto:brian.go...@oracle.com
Currently this code doesn't compile
IntConsumer c = x -> switch(x) { default -> System.out.println(x); };
I believe it should because this is the basic pattern for supporting the actor
model,
you consume a message and do a side effect* depending on the type of the
message,
translated in Java,
I lke the r prefix because most people think the r prefix means regular
expression.
Rémi
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Samedi 6 Avril 2019 17:47:25
> Objet: Fwd: String reboot (plain text)
> Received on amber-spec-comments. These are mostly comments on syntax
I really like in the syntax proposed by Jim the fact that the single quote " is
retconned to allow several lines,
it seems the easiest thing to do if we just want to introduce a multi-lines
literal string.
>From that, i agree that the more lines you have, the more you need to have a
>way to
> De: "Brian Goetz"
> À: "Kevin Bourrillion"
> Cc: "amber-spec-experts"
> Envoyé: Mardi 19 Mars 2019 00:25:58
> Objet: Re: Records and annotations
>>> - Should we treat the cases where @A has a target of RECORD_COMPONENT,
>>> separately from the cases where it does not, such as, only push the
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Lundi 18 Mars 2019 15:19:31
> Objet: Fwd: Concise method bodies with delegation and this
> Received on the -comments list.
> So, the CMB proposal was a bit of an experiment in letting a half-baked idea
> out
> of the lab a little sooner
> De: "Kevin Bourrillion"
> À: "Amber Expert Group Observers"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 15 Mars 2019 22:02:24
> Objet: Re: Updated document on data classes and sealed types
> Well, I thought of nothing to dislike about this. 99.9% of users will never
> know
> or care that
As you may know, there are two kinds of final field in Java,
you have final fields and trusted final fields, the former are classical final
fields the later are final fields that can no be changed by reflection thus are
considered as "real" final field by JITs
(see
It's a poster child for a 'let' expression instead of twisting instanceof to
work with no type
return let results = multiResolve(false) in results.length == 1 &&
results[0].isValidResult() ? results[0].getElement() : null;
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "Tagir
Hi Tagir,
- Mail original -
> De: "Tagir Valeev"
> À: "amber-spec-experts"
> Envoyé: Lundi 4 Mars 2019 04:30:09
> Objet: Patterns for arrays of specific length
> Hello!
>
> In intellij IDEA code we often see snippets like this:
>
> final ResolveResult[] resolveResults =
So records are only immutable, it's a bold move and i like that.
For beginners we offer a simple model with immutable named tuples and mutable
List and Map, very like Python.
I still think we should restrict sealed to interface only (you can always
retrofit a class or an abstract class to add a
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Mercredi 20 Février 2019 00:52:32
> Objet: Re: nest syntax alternative
> On Feb 19, 2019, at 2:50 PM, Brian Goetz wrote:
>>
>> …we are still left with the same problem of finding the source
About the formatting rules,
we can reuse the doc comment trick to use a character to specify the alignment.
String html = \"
"
"
" Hello World.
"
You have forgotten that
- if you have a sealed class (not sealed interface), using nesting has the side
effect of creating inner classes.
I don't know what is the policy of Google about inner classes that mix
enclosing class access and inheritance but i suppose they are prohibited too.
- for
Hi all,
as Brian said recently, we have an issue because we are shortening the class
declaration (with records) or wants to declare in a single compilation unit a
hierarchy of types (with sealed types) and currently Java requires that a
compilation unit can only have one public class.
One
My favorite hyphen keyword is short-circuit, i don't know where to use it, but
it's so good that we have to find a new feature to introduce it :)
As i said, i really like this proposal.
The hyphen keywords nicely solve the issue when you want to introduce a keyword
in the middle of the code,
I'm still not 100% sure that mixing the exhaustiveness and the closeness is a
good idea,
again because
- you may want closeness of non user named types
- you may want exhaustiveness not only types (on values by example)
but it makes the feature simple, so let's go that way.
Allowing public
I think i prefer break-with,
the problem of break-return is that people will write it break return without
the hyphen, break return is in my opinion too close to return if you read the
code too fast and a break return without a value means nothing unlike a regular
return.
I like break-with
You can have both !
This is basically what we are doing with lambdas, you have a structural syntax
+ a named type that are bound together using inference.
Let say we have a tuple keyword that means, value + record +
constructor/de-constructor
tuple Range(int lo, int hi) { … }
then you can
It's basically what Swift does, you have a syntactic form for
if (x instanceof P(var y))
written
if let y = (x as? P)?.y
but it can not be inversed/negated (and you can not extract more than one
variable easily).
so yes the question is where to draw the line.
I'm with Brian on this,
> De: "John Rose"
> À: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Envoyé: Mardi 8 Janvier 2019 23:55:19
> Objet: Re: Flow scoping
> On Jan 4, 2019, at 6:07 AM, Tagir Valeev < [ mailto:amae...@gmail.com |
> amae...@gmail.com ] > wrote:
>> For the record: I heavily support this. If then-branch
- Mail original -
> De: "Brian Goetz"
> À: "Jim Laskey"
> Cc: "amber-spec-experts"
> Envoyé: Dimanche 6 Janvier 2019 18:43:19
> Objet: Re: Enhancing Java String Literals Round 2
> As Reinier pointed out on amber-dev, regex strings may routinely contain
> escaped
> meta-characters — +,
> De: "Tagir Valeev"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 4 Janvier 2019 15:07:44
> Objet: Re: Flow scoping
> Hello!
>> This is certainly this intuition that guided us here; it should be possible
>> to
>> freely refactor
>> if (e)
>> throw x;
>> else { stuff }
- Mail original -
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mardi 11 Décembre 2018 21:08:38
> Objet: Flow scoping
> (Note to observers: we did an internal survey so I could gauge the
> comfort level of the EG with the flow scoping rules for pattern binding
> variables.
There is also a non empty intersection between a sum type and an enum type,
obviously you can swith on both of them, but more generally an abstract enum
(an enum that uses subclassing) is a specialized version of a sum type. And if
we generalize sum types to allow constants, we are bridging the
Hi Doug,
using colon ':' will cause trouble to people that discover Java after having
used C or C# given that ':' is used to introduce supertypes in those languages.
Your proposed compact declaration is a mess visually if you declare a subtype
which is a sealed interface with a list of
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Vendredi 7 Décembre 2018 17:38:53
> Objet: Re: Sealed types
> I’ve updated the document on sealing to reflect the discussion so far.
> Sealed Classes
> Definition. A sealed type is one for which subclassing is restricted according
> to
Hi Maurizio,
i think you have overlook the fact that raw types and inference also doesn't
play well together.
accessibility:
Widening the type is usually a big No because of the security implication. The
fact that the same code code has no security bug with version n but a security
hole with
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mardi 27 Novembre 2018 23:20:54
> Objet: Sealed types
> Since we’re already discussing one of the consequences of sealed types, let’s
> put the whole story on the table. These are my current thoughts, but there’s
> room in the design space
> De: "John Rose"
> À: "Kevin Bourrillion"
> Cc: "amber-spec-experts"
> Envoyé: Mardi 27 Novembre 2018 03:04:01
> Objet: Re: Lifting the restriction on the number of public classes per file
> On Nov 26, 2018, at 11:43 AM, Kevin Bourrillion < [ mailto:kev...@google.com |
> kev...@google.com ] >
> De: "Kevin Bourrillion"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Lundi 26 Novembre 2018 20:43:37
> Objet: Re: Lifting the restriction on the number of public classes per file
> Sorry for delay. Can we unpack the "for whatever reason" part? For what
> reason?
> Unsurprisingly
Hi everybody,
i think there are two ideas that worth think about now that the expression
switch will be released soon that are not related to the elephant in the room,
the pattern matching.
First, a statement switch can use the arrow syntax with an expression that
throw an expression.
[move to amber-spec-experts]
- Mail original -
> De: "Brian Goetz"
> À: "amber-dev"
> Envoyé: Lundi 22 Octobre 2018 21:45:00
> Objet: New draft JEP: intrinsics for String::format and Objects::hash (among
> others)
> For those of you following the saga of improved constant folding,
- Mail original -
> De: "Brian Goetz"
> À: "John Rose"
> Cc: "amber-spec-experts"
> Envoyé: Samedi 13 Octobre 2018 15:22:12
> Objet: Re: `this` in concise method bodies
> John makes some good arguments for the value of the :: form of CMBs;
> that they raise the level of reuse from
oops,
it the reply button too soon.
Rémi
>> De: "John Rose"
>> À: "Remi Forax"
>> Cc: "Brian Goetz" , "amber-spec-experts"
>>
>> Envoyé: Samedi 13 Octobre 2018 07:00:09
>> Objet: Re: `this` in concise method bodi
Hi Daniel,
- Mail original -
> De: "daniel smith"
> À: "amber-spec-experts"
> Envoyé: Mardi 9 Octobre 2018 18:31:48
> Objet: Re: New JEP: Concise Method Bodies
>> On Oct 8, 2018, at 12:14 PM, Dan Smith wrote:
>>
>> - Type-qualified method ref: if you don't pass 'this' to the method,
> De: "daniel smith"
> À: "amber-spec-experts"
> Envoyé: Samedi 6 Octobre 2018 01:22:25
> Objet: Re: New JEP: Concise Method Bodies
>> On Oct 5, 2018, at 4:18 PM, Brian Goetz < [ mailto:brian.go...@oracle.com |
>> brian.go...@oracle.com ] > wrote:
>>> Can the expression before the :: refer to
> De: "Kevin Bourrillion"
> À: "Alex Buckley"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 5 Octobre 2018 22:03:53
> Objet: Re: New JEP: Concise Method Bodies
> On Mon, Sep 24, 2018 at 10:17 AM Alex Buckley < [
> mailto:alex.buck...@oracle.com
> | alex.buck...@oracle.com ] > wrote:
>> On
I wonder if the concise method body proposal should not be extended to add
parameters types/return type inference in case of overriding methods.
The idea is that in case of a method overriding a method or implementing an
abstract method the return type and the type parameters are optional like
Testing the prototype, i've seen myself using -> null instead of a classical
empty method body when i want to have a method that does nothing.
class A {
void f() -> null;
// versus
void f() {
}
}
the compiler translates the concise version to aconst_null pop return instead
of a plain
Hi all,
i've played a little bit with the concise method prototype.
i think that using '=' to 'assign' a method reference to a method signature
- is visually too close to a field assignment.
- send the wrong message because there is no assignment at runtime.
A way to avoid the issue listed above
201 - 300 of 352 matches
Mail list logo
