Re: [java-gnome-hackers] sourceview development branch

[Andrew C. <an...@op...>]

On Thu, 2009-05-21 at 10:03 +0200, Stefan Schweizer wrote:
> On Thu, 2009-05-21 at 09:48 +1000, Andrew Cowie wrote:
> > The only thing that really caught my eye so far was
> > LanguageManager.getDefault(); my *personal* taste is that I dislike
> > static functions anywhere other than library initialization.
> 
> Another option would be to turn LanguageManager into a real singleton
> and only call that function when the singleton instance is created. The
> LanguageManager would then be accessed like this:
> LanguageManager.getInstance(); that does not remove the static method
> but would make it more explicit that you are using one. Maybe that would
> fit better?

Nah, not really.

The whole "here's a class which has a factory method which you use to
get the only instance of the class which you then use to lookup an item
in the group that that class manages" thing is fairly common Java and
what I hate so much about most Java libraries. I'm a bit saddened to see
that we're forced to deal with this coming from a GNOME library.

Oh well.

++

As I was reading through this branch this afternoon, I noticed that you
don't have a no-arg SourceBuffer constructor.

So here's something you might look at: punch up TextBuffer and TextTag
have a look at how we able to avoid people having to use TextTagTables
if they don't really feel like it.

Because

        buffer.setLanguage(LanguageManager.getDefault().getLanguage("java"));

is moderately horrid, even when written more clearly as

        manager = LanguageManager.getDefault()
        java = manager.getLanguage("java");
        buffer.setLanguage(java);
        
it still seems a lot of work.

[Admittedly GUI programming is always a lot of work, but nevertheless]

The real question that is bothering me is "would you ever have any
reason to have a LanguageManager other than the default one?" My guess
is no.

So let's see.

Normally I'm pretty obsessive about strong typing, and the idea of
strongly-typed Language instances seems fine. Fair bit of work to get
at, as we've seen. So part of me wonders if we couldn't compress that a
bit.

If it wasn't for the fact that I just asserted how important strong type
safety is, I'd almost be tempted to suggest:

        buffer.setLanguage("java");

but... no.

Hm.

Dare I suggest preconfigured constants, ie Language.JAVA maybe? See
org.gnome.gtk's PaperSize.A4 and friends. So have a look at that, have a
look at the no-arg TextTag() and no-arg TextBuffer() constructors. While
you're at it, see org.gnome.gtk's Statusbar for an example of where we
just engineered around something that was silly.

See if any of these spawn any bright ideas.

[obviously the risk with preconfigured constants is we don't want to
force GtkSourceView to load all kinds of stuff if we aren't going to
need it, and initializing constants has a tendency to do that unless
you're careful about being lazy]

++

Weighing against all of this is "we only diverge the API mapping if
we've got a good reason to" but avoiding intermediate factory classes
that don't do anything are in the category of good reason, IMHO.

Failing all that, it seems like the static method could simply be on
Language, leaving LanguageManager out of it entirely. Again - if there's
more purpose for that class, fine, but it sure doesn't seem that way.

++

Other than this API question, the branch is in *excellent* shape and I
am prepared to accept it into java-gnome. Fantastic work.

AfC
Sydney


-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London