abstract layouts

[Maurizio Cimadamore]

May I suggest, for the benefit of the conversation, that instead of 
focusing on the _hows_ we focus instead on the _whys_ ?

E.g. "I'd like to decorate a layout with information X and Y, because I 
use these information in order to do Z"

In other words, by having a full picture of what you are trying to do we 
might understand better what the requirements really are.

Thanks
Maurizio

On 12/08/2021 14:12, Maurizio Cimadamore wrote:
>
> On 12/08/2021 12:24, Ty Young wrote:
>> I'd very much like it if layouts were opened up and non-sealed. It 
>> would allow for less wasteful(no Optional) and faster code(no 
>> HashMap, things can be final). 
> I agree that would work better.
>
>> It also would be nice if GroupLayout was removed and replaced with 
>> StructLayout and UnionLayout, or used as a shared/common 
>> interface/class for them.
> That is largely orthogonal and irrelevant in the discussion we're 
> having here.
>>
>>
>> I feel like the with* issues could be fixed with generics, e.g.:
>>
>>
>> public interface MemoryLayout<L extends MemoryLayout<?>> {
>>
>>     public L withName(String name);
>>
>> }
>
> I don't think this solves much - as you will have, likely:
>
> ValueLayout extends MemoryLayout<ValueLayout>
>
> At which point you're back to square one - if you define `TyLayout 
> extends ValueLayout`, there's nothing forcing you to override withName.
>
> I did experiments adding generic types to all layouts two years ago 
> and honestly, it doesn't work very well. About 99% of the times, the 
> most helpful thing the client has to say about a layout is 
> MemoryLayout<?>, which seems like forcing 99% of the users to use 
> generics because 1% of use cases might need them. But that's beside 
> the point - generics do not solve the problem I was talking about. 
> Also, in my experience, having f-bounded type variables in hierarchies 
> works very well when you have one top class and a single level of 
> leaves (which are all peers). It works much less when you have to 
> start defining sub-hierarchies in the leaves - because either the 
> intermediate nodes are conscious about the type variables and leave 
> them open (leading to very verbose and borderline uncomprehensible 
> generic declarations), or they fix the type variables, in which case 
> the leaves will not take advantage of the f-bound, and you'll be back 
> in no-generic-land.
>
>
>>
>> All of the basic layout types should be interfaces, not classes IMO. 
>> Basic implementations could be put in a non-exported package. Users 
>> can get a basic implementation from MemoryLayout static methods, as 
>> they do now.
> Again, this seems a bit of a shallow comment. We can turn layouts from 
> interface to classes in 2 minutes, by doing a targeted refactoring. 
> But again, whether classes or interfaces, the problem I pointed out is 
> still there and is the one we'd need to solve to be able to let 
> clients to subclass layouts freely.
>>
>>
>> I don't think what I'm proposing could be done with static decorator 
>> methods. The information being added as attributes include 
>> MethodHandles for the class's constructor, e.g. a constructor 
>> MethodHandle for a NativeInteger class, something that specific can 
>> only be done at the class level I think.
>
> Well, the original proposal was to add a bunch of methods:
>
> * MemoryLayout::isAbstract
> * MemroyLayout::asAbstract
> * MemoryLayout::unfilledAttributes
>
> If we have layout attributes (like we do in today's API), there is no 
> need for these methods to _be_ in MemoryLayout. They can be static 
> methods taking a layout, defined wherever you want. Just use a special 
> name to encode the attribute names - e.g. "abstract/foo" - then:
>
> * isAbstract --> does the layout have any attribute whose name starts 
> with "abstract/" which are set to null?
> * asAbstract --> encode the attribute names to use the "abstract/" prefix
> * unfilledAttributes -> get all the attributes whose name start with 
> "abstract/" and return those that have no value set
>
> Maurizio
>
>
>
>