Classfile API proposal to integrate basic print functionality directly to ClassModel and MethodModel

[Brian Goetz]

If "block" means multi-line, and non-block means single-line, I'm 
confused as to why we have

    public record Mapping(String key, List<Fragment> fragments) 
implements Printable {}
but
    public record BlockMapping(String key,  List<Printable> printables) 
implements Printable {}

where one has fragments and the other only has Printables. Similarly, we 
have

     public record ValueList(String key, List<ConstantDesc> values) 
implements Fragment {}
     public record BlockList(String key, List<BlockMapping> 
blockMappings) implements Printable {}

where again the List element differs.   Is there no way to make the 
block/non-block orthogonal to the payload type?  That would allow us to 
replace the two BlockXxx(...) with different payloads, with a Block<T> 
wrapper as a formatting hint.


On 7/25/2022 1:51 PM, Adam Sotona wrote:
>
> Further reduction will require additional info about formatting. 
> Actual list has very simple printers implementations:
>
> switch(node) {
>
> case/Value/ v ->
>
> case/ValueList/ vl ->
>
> case/Mapping/ m
>
> case/BlockList/ bl ->
>
> case/BlockMapping/ bm ->
>
> case/Comment/ c ->
>
>             }
>
> Replacing all simple values with list of values will wrap everything 
> into square brackets and significantly reduce user readability.
>
> Or dynamic detection of single value in a list will destroy any schema 
> for parsing.
>
> Visual difference of rendered Mapping and BlockMapping is significant 
> in all three formats.
>
> The key here means a mapping key in YAML, object key in JSON and 
> element or attribute name in XML, so it defines a key in the schemas.
>
> BlockMapping renders as multi-line mapping in YAML, as multi-line 
> object in JSON and as multi-line nested elements in XML.
>
> While Mapping renders as single-line flow in YAML, as single-line 
> object in JSON and as single  element with attributes only in XML.
>
> Dynamic detection by content will make the print very unstable and 
> unfriendly for user reading (for example one method will be collapsed, 
> while the other will expand).
>
> I don’t see much space for reduction without losing visual features.
>
> On 25.07.2022 19:28, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>
>
> That's a good move.  Can we push further? We have types here for 
> mapping a key to a:
>
>  - list of simple values
>  - list of arbitrary fragments
>  - list of printables
>  - list of list of printable (blocklist)
>
>
> On 7/25/2022 1:20 PM, Adam Sotona wrote:
>
>     Or maybe we could let the printer to auto-quote as needed by the
>     actual value in the context of the actual format 😊
>
>     So yes, it can be reduced:
>
>     publicsealedinterface*Printable* {
>
>     publicString *key*();
>
>     publicsealedinterface*/Fragment/* extendsPrintable {}
>
>     publicrecord/Value/(String key, String ConstantDesc value)
>     implements/Fragment/ {}
>
>     publicrecord/Quoted/(String key, String value) implements/Fragment/ {}
>
>     publicrecord/Decimal/(String key, intvalue) implements/Fragment/ {}
>
>     publicrecord/ValueList/(String key, List<StringConstantDesc>
>     values) implements/Fragment/ {}
>
>     publicrecord/QuotedList/(String key, List<String> values)
>     implements/Fragment/ {}
>
>     publicrecord/Mapping/(String key, List</Fragment/> fragments)
>     implementsPrintable {}
>
>     publicrecord/BlockMapping/(String key,  List<Printable>
>     printables) implementsPrintable {}
>
>     publicrecord/BlockList/(String key,  List</BlockMapping/>
>     blockMappings) implementsPrintable {}
>
>     publicrecord/Comment/(String key) implementsPrintable {}
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220725/3c3e9d01/attachment-0001.htm>