Re: Some suggestions

This is a multi-part message in MIME format...

------------=_1591370197-19591-15
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

----- Mail original -----
> De: "Remi Forax" <[email protected]>
> =C3=80: "asm" <[email protected]>
> Envoy=C3=A9: Vendredi 5 Juin 2020 15:43:53
> Objet: Re: [asm] Some suggestions

> This was ask as a gitlab issue but given that it's more a discussion,
> i move it to the mailing list
>=20
>> Aura Lee wrote:
>> It is pretty annoying that some classes like Subroutine are final and
>> non-public. Because of that, I cannot extend the Analyzer class.
>> You may think that users won't need to extend the Analyzer class because=
 there
>> is an > Interpreter interface, but in my case need it,
>> as i want to handle edges of jumps with a known outcome differently. The=
 same
>> applies to MethodWriter and other classes.
>>
>> Another thing that bothers me is that InvokeDynamicInsnNode has a public
>> bsmArgs[], but ConstantDynamic only has a private one with get / set met=
hods.
>> This is pretty annoying when i want to iterate over the args.
>>
>> Also think about implementing those methods in the Type class:
>>   public Type toArray(int dimensions)
>>   public static Type getOpcodeReturnType(int opcode)
>>   public static Type[] getOpcodeArgumentTypes(int opcode)
>>   public static Type getGenericType(int sort)


Hi Aura,
ASM reflects the Java VM specification (the chapter 4) and given that Java =
evolves, we have to adapt ASM to new changes, some are simple like the new =
Record attribute, some are really complex like the introduction of the Stac=
kMap attribute. ASM is also widely used to the point we have decided to pro=
vide a fully backward compatible (since ASM 4).

To satisfy those constraints, we try to not expose the inner working of ASM=
 so we change the implementation of ASM (it already happen several times) w=
ithout changing the API.
So we have chosen to not expose a class like Subroutine because it will ham=
per us to change it in the future.

About InvokeDynamicInsnNode vs ConstantDynamic, InvokeDynamicInsnNode shoul=
d not expose its fields, but any nodes in ASM works that way and it will be=
 an incompatible change to change that now.
ConstantDynamic was introduced recently (Java 11) so it's using a better en=
capsulation scheme.

About adding more methods to Type, i don't know, Type is more a bunch of he=
lper functions that a real type, it's not fully true, because a ldc class/m=
ethodtype are using Type,
but if you want a fully featured class to represent classfile constant, usi=
ng the classes of java.lang.constant [1] is perhaps better idea.

regards,
R=C3=A9mi

[1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/=
constant/package-summary.html

------------=_1591370197-19591-15
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit


-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

------------=_1591370197-19591-15--