On Wed, 10 Jan 2024 18:27:45 GMT, Pavel Rappo wrote:
> > /contributor add @pavelrappo
>
> Thanks, Joe. Making me an "overriding author" was a bit over the top. :)
Skimmed the docs too quickly when looking for a "co-author" command :-)
-
PR Comment:
On Wed, 10 Jan 2024 18:16:05 GMT, Joe Darcy wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec,
On Wed, 10 Jan 2024 18:16:05 GMT, Joe Darcy wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec,
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
On Tue, 9 Jan 2024 19:37:54 GMT, Joe Darcy wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec,
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
On Mon, 8 Jan 2024 22:29:47 GMT, Joe Darcy wrote:
>>> Since it doesn't seem possible to do so, I did not attempt to relay
>>> "non-sealed" information in this PR :-)
>>
>> Naively, I thought that something like this is possible _in principle_; I
>> might be mistaken though:
>>
>> diff --git
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
On Wed, 3 Jan 2024 19:44:51 GMT, Pavel Rappo wrote:
>> I think the best place, or least-bad place, to discuss the "modifier"
>> ordering of sealed/non-sealed would be an informative note on
>> Modifier.toString(int) -- "The sealed/non-sealed Java language modifiers are
>> not represented in
On Wed, 3 Jan 2024 22:20:15 GMT, Joe Darcy wrote:
>>> Since it doesn't seem possible to do so, I did not attempt to relay
>>> "non-sealed" information in this PR :-)
>>
>> Naively, I thought that something like this is possible _in principle_; I
>> might be mistaken though:
>>
>> diff --git
On Wed, 3 Jan 2024 19:44:51 GMT, Pavel Rappo wrote:
>> I think the best place, or least-bad place, to discuss the "modifier"
>> ordering of sealed/non-sealed would be an informative note on
>> Modifier.toString(int) -- "The sealed/non-sealed Java language modifiers are
>> not represented in
On Wed, 3 Jan 2024 18:16:24 GMT, Joe Darcy wrote:
> Since it doesn't seem possible to do so, I did not attempt to relay
> "non-sealed" information in this PR :-)
Naively, I thought that something like this is possible _in principle_; I might
be mistaken though:
diff --git
On Wed, 3 Jan 2024 06:43:22 GMT, Joe Darcy wrote:
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec,
On Wed, 3 Jan 2024 16:40:32 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/lang/Class.java line 264:
>>
>>> 262: /**
>>> 263: * Returns a string describing this {@code Class}, including
>>> 264: * information about modifiers, {@linkplain #isSealed() sealing},
>>> and
On Wed, 3 Jan 2024 14:52:48 GMT, Roger Riggs wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec,
On Wed, 3 Jan 2024 14:59:33 GMT, Roger Riggs wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec,
On Wed, 3 Jan 2024 06:43:22 GMT, Joe Darcy wrote:
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec,
As recently discussed on core libs, sealed-ness information could be included
in the Class.toGenericString() output, analagous to how "modifiers" that also
correspond to JVM access flags are handled.
This is the initial spec, implementation, and test updated needed for that
change. If there is
21 matches
Mail list logo
