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
I'd also add the Tapestry-IoC classes that create service proxies.
On Thu, 20 Feb 2014 11:03:09 -0300, Lance Java
wrote:
Possibly the most comprehensive use of plastic is the test cases
https://github.com/apache/tapestry-5/tree/master/plastic/src/test/groovy/org/apache/tapestry5/plastic
Af
Possibly the most comprehensive use of plastic is the test cases
https://github.com/apache/tapestry-5/tree/master/plastic/src/test/groovy/org/apache/tapestry5/plastic
After that, it's worth checking out Taha's blog
http://tawus.wordpress.com/category/plastic/
Perhaps give a high level overview of what you're trying to achieve. Can it
be achieved using:
PlasticClass.introduceMethod(...) and
PlasticMethod.addAdvice(MethodAdvice)
On Thu, 20 Feb 2014 09:10:45 -0300, Philip Aston wrote:
I'll work one up. I couldn't implement existing interface methods either.
Tapestry-IoC does an awful lot of that (creating classes to implement an
interface) when creating proxies to services defined by an interface.
Yeah, I think t
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
>> existing classes, and I originally tr
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
existing classes, and I originally tried to do so but found Plastic
didn't let me implement abstract met
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
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 code.
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
>>> instructions? As far as I know, Howard c
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
instructions? As far as I know, Howard created Plastic so he didn't
need to use ASM directly in Tapestry-IoC.
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 my previous mail is the place
>> I currently need the method
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 my previous mail is the place
I currently need the method visitor; specifically so I can create an
array to pass to String.format().
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 underlying ASM method
>> visitor, and provides no other
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 underlying ASM method
visitor, and provides no other way to add arbitrary byte code?
Why do you need that? Just curious. :)
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
16 matches
Mail list logo