[stringtemplate-interest] StringTemplate + Doclet

[Collin Fagan]

I ran into something like this when I was processing annotations. All
annotations are interfaces and implemented with Proxy objects at runtime,
hence you can't set a renderer for them. The only problem with
isAssignableFrom is that it is not a one-to-one mapping like comparing
classes is. How would one handel an object that isAssignableFrom multiple
registered interfaces or classes?

Collin

On Wed, Dec 22, 2010 at 1:43 PM, Terence Parr <parrt at cs.usfca.edu> wrote:

> Ah. right! Class.isAssignableFrom is the ticket.
>
> @Sam, caching. you mean recording each o.getClass() -> isAssignableFrom
> mapping?
>
> Seems I should upgrade regiserRenderer too...grr...
>
> Ter
> On Dec 22, 2010, at 10:47 AM, Rafael Chaves wrote:
>
> > For any interface based API (which is a common practice), getClass()
> > is a show stopper. A client of the API does not know the actual
> > classes involved (they are not API).
> >
> > I was not suggesting actually using the instanceof operator (I am not
> > sure you really meant that, as it is not really possible), but
> > Class.isInstanceOf(object). A similar thing would be
> > Class.isAssignableFrom(object.getClass()).
> >
> > Cheers,
> >
> > Rafael
> >
> > On Wed, Dec 22, 2010 at 10:06 AM, Terence Parr <parrt at cs.usfca.edu>
> wrote:
> >> Seems like I could do instanceof by just walking the
> Class.superClass/implements chain, right?  I'm not considering generating
> code; makes it hard to port ;)
> >> Ter
> >> On Dec 22, 2010, at 10:01 AM, Brian Clapper wrote:
> >>
> >>> On 12/22/10 12:51 PM, Terence Parr wrote:
> >>>>
> >>>> On Dec 22, 2010, at 9:38 AM, Brian Clapper wrote:
> >>>>>> contract), I ended up using ASM to generate interfaces on the fly,
> which I then
> >>>>> implement via java.lang.reflect.Proxy.
> >>>>
> >>>> BTW, for renderers i did == on obj.getClass() not instanceof (which
> only works
> >>>> on class names not Class ptrs).  Is it a serious problem if i don't
> allow
> >>>> instanceof?  Maybe if the model object is hidden by interfaces like
> jdbc.
> >>>> hmm... i'd rather avoid the java.lang.reflect.Proxy stuff.
> >>>
> >>> I don't use instanceof, so it won't affect me.
> >>>
> >>> I deliberately chose java.lang.reflect.Proxy, for a couple reasons.
> First,
> >>> generating the byte code for an interface, via ASM, is straightforward
> and
> >>> simple. Generating a wrapper class, on the other hand, is more
> complicated and
> >>> annoying. Second, using Proxy to implement an interface on the fly is
> also
> >>> straightforward.
> >>>
> >>> This technique allows for more maintainable code, in my opinion. If I'm
> going
> >>> to resort to generating byte code on the fly, I'd like that part of the
> >>> solution to be a dead-simple as possible. Use of Proxy made that
> possible. If I
> >>> weren't generating the byte code for the wrapper interface on the fly,
> I
> >>> wouldn't be using Proxy at all.
> >>>
> >>> If I could get rid of byte code generation entirely, it'd be a real
> win.
> >>> --
> >>> -Brian
> >>>
> >>> Brian Clapper, http://www.clapper.org/bmc/
> >>> _______________________________________________
> >>> stringtemplate-interest mailing list
> >>> stringtemplate-interest at antlr.org
> >>> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
> >>
> >> _______________________________________________
> >> stringtemplate-interest mailing list
> >> stringtemplate-interest at antlr.org
> >> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
> >>
> > _______________________________________________
> > stringtemplate-interest mailing list
> > stringtemplate-interest at antlr.org
> > http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20101222/9e07d67a/attachment-0001.html