Having created a test case, I found what I was doing wrong. I was
expecting PlasticField.createAccessors() to understand covariant return
types, and so "pc.introduceField(Foo.class).createAccessors(..)" would
override "Object getFoo()"; it doesn't.
I now have everything working without the need fo
On 20/02/14 12:08, Thiago H de Paula Figueiredo wrote:
> On Thu, 20 Feb 2014 08:11:35 -0300, Philip Aston
> wrote:
>
>> Well, the InstructionBuilder API requires you to understand the byte
>> code that's generated. Also, I agree that it is sane to transform
>> ex
On 20/02/14 08:30, Lance Java wrote:
> I think the whole philosophy of Plastic is that you shouldn't ever need to
> use ASM directly. I'm no expert but my understanding is that you can write
> normal java code by implementing interfaces and use Plastic to weave the
> implementations into the byte c
On 19/02/14 17:13, Thiago H de Paula Figueiredo wrote:
> On Wed, 19 Feb 2014 11:48:10 -0300, Philip Aston
> wrote:
>
>>> I don't know. My ASM/bytecode experience is almost null. Is Plastic
>>> missing methods or other stuff so you can use some specific
>>&g
On 19/02/14 14:45, Thiago H de Paula Figueiredo wrote:
> On Wed, 19 Feb 2014 11:13:30 -0300, Philip Aston
> wrote:
>
>> Maybe I don't?
>>
>> I'm using Plastic standalone, without Tapestry.
>>
>> The "toString" implementation I showed in m
On 19/02/14 14:08, Thiago H de Paula Figueiredo wrote:
> On Wed, 19 Feb 2014 09:37:14 -0300, Philip Aston
> wrote:
>
>> Hello,
>
> Hi!
>
>>
>> Unless I'm missing something, Plastic prevents an
>> InstructionBuilderCallback from accessing the underlyi
Hello,
Unless I'm missing something, Plastic prevents an
InstructionBuilderCallback from accessing the underlying ASM method
visitor, and provides no other way to add arbitrary byte code?
Plastic is very useful, and way more pleasant than raw ASM, however I've
found I need to go off the tracks oc
