Re: [ jEdit-devel ] EditBus messages and message handling

[Dale A. <da...@gr...>]

I've attached my modified EditBus.java file, hopefully it'll make it
through the spam filters.  I hadn't thought of your reflection idea,
that would reduce the if/else constructs that everyone is using now.

Dale


On Thu, Sep 10, 2009 at 5:02 PM, Marcelo Vanzin
<va...@us...> wrote:
> On Thu, Sep 10, 2009 at 3:09 PM, Dale Anson <da...@gr...> wrote:
>> 1.  All EBComponents get sent every message, regardless of whether
>> they care about all those messages.  Usually, an EBComponent only
>> cares about one or two message types.
>
> I like the concept but I don't know if I like your planned execution
> (or what I understand of it). From what I understood, the plugin would
> get the messages it subscribed to, but still would have to multiplex
> them (today using instanceof to check the type).
>
> What if instead of doing subscription this way this was done more
> dynamically using reflection?
>
> A quick idea of how to do it: create a convention that any method
> called "handleMessa ge" (or "handleEBMessage" if the former is too
> generic) is targeted at handling an EBMessage. When dispatching
> messages, the code checks the sink for a specific method matching the
> incoming message type (e.g., if the incoming type is "ViewUpdate", the
> dispatcher looks for "handleEBMessage(ViewUpdate)"). If a handler is
> not found, it looks for a generic "handleEBMessage(EBMessage)" method.
> If no handler is found, just ignore that sink.
>
> The dispatcher could cache the type -> handler mappings if reflection
> is too expensive. The only issue there is that, since EBComponent is
> an interface and not a class, flushing the cache might be tricky since
> we can't keep it in a base class. (Or maybe not, maybe it's as easy as
> doing it when the EBComponent is removed from the bus).
>
> This doesn't cover the event's "what" multiplexing that Shlomy
> mentions, but I think it is a cleaner approach than your subscription
> model. It could also have problems with class loaders getting confused
> (similar to the instanceof issues you mention, although I've never
> seen them), but if that happens I think it's a lower level issue with
> the class loaders that we should fix.
>
> --
> Marcelo Vanzin
> mmv...@gm...
> "Life's too short to drink cheap beer."
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>