Blog moved to The.Berlin.Factor

Alright, with all the posted code samples in the last few days I finally had enough of non-intuitive Blogger editing. Not that WordPress solved all my editing needs right away, but I really only needed an excuse to setup my own blog.. In the end I will have to write my own blog software anyway.. :)

From now on I'll post new stuff at The.Berlin.Factor.

tfdj

I don't like annotations

Call me crazy, but I really don't like annotations. Those weird things used in Java and .NET..

Let me show you some examples why I don't like them: (And yes, there are probably some examples why they are good.. or at least why they seem to be good..)

From the RhinoMocks documentation:

[SetUp]
public void Setup()
{
mocks = new MockRepository();
}

What does [SetUp] tell us about "Setup"? :) And the same thing happens for the TearDown method, of course.. And really, why is this

[Test]
public void CallMethodOnObject()

better than

public void testCallMethodOnObject()

Alright, there are reasons why the annotated version is better. You may not be able to 'reflect' on a class to get all the methods for which the name starts with "test", and there may be ambiguities.. But are annotations solving these problems 'better enough' to accept the penality of this added language complexity? And it is added complexity, isn't it?

What is even more interesting is the fact that in the same example code from the RhinoMocks site you find lines like this:

IDemo demo = (IDemo)mocks.CreateMock(typeof(IDemo));

Look at some recent posts like Sacred Code Cows and Talking Dynamic Languages which basically say that an I for an interface is at least a bit strange. Probably much worse than strange..

There's more! :)

So I implemented this Syntax Highlighther plugin for IDEA during the last evenings. Look at some of the signatures of methods I had to implement:

@NotNull
public final String getDemoText()

@Nullable
public final StructureViewBuilder getStructureViewBuilder( final @NotNull VirtualFile file, final @NotNull Project project )

@NotNull
@NonNls
public final String getDefaultExtension()

For me it just feels like the wrong approach.. It's much like being a codified part of the contract between caller and callee. That's ok. But does it look nice? Does it look 'right' in a stylish way? For me it has one of these bad smells..

If you'd really like to make the code speak the truth - as much as possible - why not use something like this:

public interface Something
{
public final ExtensionString getDefaultExtension();
}

public final class ExtensionString
{
public static final ExtensionString newInstance( final String aExtension )
{
if ( isValidAndCorrect( aExtension ) == false )
{
throw new YouSuckException( aExtension );
}
return new ExtensionString( aExtension )
}

(...)

// From Object

public final String toString()
{
return myExtension;
}

// Implementation Details

private ExtensionString( final String aExtension )
{
myExtension = aExtension;
}

private static final void isValidAndCorrect( final String aExtension )
{
(...)
}

private final String myExtension;
}

Use what the language core offers you! And don't give me the performance BS.. What's your main priority? Performance or correctness? Or..? Decide that first, then be disciplined about it and follow through with it..

Anyway, just a thought.. And don't ask me about C++ template (meta) programming.. In your on frikin interest.. :)

tfdj

Update 3: Ruby Plugin for IDEA

Alright. Took me nearly three whole evenings to conquer IDEA. I've seen lots of little things I really dislike.. Globals and other BS.. Horrible..

Well. I got an initial configurable version of the "SimpleSyntax" highlighter plugin done. It's available here as binary and source. These files will probably go away soon, after I created an official project somewhere. But some heavy cleaning up has to happen first..

Anyway, some of the nice bits of this plugin. Have a look at a configuration as it is supported right now:

[SimpleSyntax:V1.0]

Name: Ruby
Icon: simplesyntax_ruby.png
Description: Ruby Script File
ExampleCode: simplesyntax_ruby.rb

# Braces Configuration
Braces.Pairs: (),[]
Braces.Structural: {}

# Commenter Configuration
Comment.Line: #
Comment.BlockPrefix:
Comment.BlockSuffix:

# FileType Configuration
FileType.Icon: simplesyntax_ruby.png
FileType.Extensions: rb, ruby
FileType.DefaultExtension: rb

# Syntax Configuration
regex BLOCK_COMMENT => (?m)^(?:\s*#.*$){2,}
regex LINE_COMMENT => (?m)#.*$
(...)
regex SPECIAL_QUOTED_STRING => %[qQ](.).*\1
regex SINGLE_QUOTED_STRING => \'(?:[^\']|\\')*\'
regex DOUBLE_QUOTED_STRING => \"(?:[^\"]|\\")*\"
(...)

# Element Descriptions
descriptions[ BLOCK_COMMENT ] = Block comment
descriptions[ LINE_COMMENT ] = Line comment
descriptions[ DOC_COMMENT ] = Documentation
(...)

# Element Default Attributes
attributes[ BLOCK_COMMENT ] = #303030,BOLD,ITALIC
attributes[ LINE_COMMENT ] = #305030,BOLD,ITALIC
attributes[ DOC_COMMENT ] = #503030,BOLD,ITALIC
(...)

I removed the dirty/incomplete parts.. :) Support for easier keyword specification, etc is still missing. For now only the "regex" rules are supported. Which is pretty clumsy for specifiying keywords..

Another "nice" thing I want to add are "ruby" and "groovy" rules in which some script code is executed to recognize tokens - instead of RegEx matching. We'll see..

That's it for today.. BF2 is waiting.. :)

tfdj

Update 2: Ruby Plugin for IDEA

I've been pretty busy with work all day. Now I got back to the IDEA Ruby plugin and after only a few minutes of thinking about what I was going to do, I said to myself "Wait a minute.. that's BS..". There's a much simpler solution..

Alright, here's the context: Yesterday I spent a few hours trying to use a 'search-replace' approach for turning the JavaScript IDEA example plugin into a Ruby plugin. Didn't work.. :) And after a few minutes playing around with JFlex.. well, it really was enough JFlexing for a lifetime.. I then started implementing the Lexer interface offered by IDEA again, keeping in mind that at some point I'd have JRuby doing the 'tokenizing'.

But while doing that, I 'stumbled' across a simpler idea. How about a concept called 'RecognizedToken', offering a simple API like this:

interface RecognizedToken
{
boolean isFoundIn( CharSequence, StartOffset, EndOffset );
int getTokenStart();
int getTokenEnd();
IElementType getTokenType();
}

Then it should be possible to implement a very simple Lexer checking all registered tokens on every 'advance' call. This Lexer could read a simple config file consisting of lines such as:

LINE_COMMENT => "#.*"
DOUBLE_QUOTED_STRING => "\"(?:[^\"]|\\\")*\""
(...)

Of course, the next problem is the complexity of the regular expressions. And performance could be an issue, if IDEA doesn't properly cache the Lexer output. But judging from the 'start' method signatures, my guess is they will cache everything..

Anyway, the Lexer now becomes a simple "10" liner. Well, apart from the 100 LOC used to implement the generic API..

private final void updateTokenType( final int aStartOffset )
{
myTokenStart = aStartOffset;
myTokenEnd = myEndOffset;
myTokenType = null;

final RecognizedToken recognizedToken = myTokenFinder.findClosest( myCharSequence, aStartOffset, myEndOffset );
if ( recognizedToken == null ) return;

myTokenType = recognizedToken.getTokenType();
myTokenStart = recognizedToken.getTokenStart();
myTokenEnd = recognizedToken.getTokenEnd();
}

The basic Lexer is working now. I'll add configuration file support and then try some Ruby coding in IDEA with this plugin's syntax highlighting enabled.

tfdj

Update: Ruby Plugin for IDEA

It's been a busy week. Not much time for my fun projects.. Only today I started looking back into the Ruby plugin for IDEA. I see two ways that I'm willing to follow:

1. Embed JRuby into the Plugin and offer a Ruby-bases configuration file for the syntax definitions.

2. Clone the JavaScript example plugin and do a string-replace "JavaScript" to "Ruby".

I actually like the first idea a lot more. And it's much closer to my current solution, which is basically a hack using hardcoded lexer, keywords, etc.. I like the idea of having a simple config syntax to define the keywords and other parts of the languages that I want to hilight. Obviously there may be some performance issues..

The second idea, cloning the JavaScript thing, well.. it's huge! And using JFelx for the lexer is nearly overkill.. imho.. :) I simply don't like these 'theoretically correct' but not too pragmatic/usable solutions..

tfdj

TFDJ is on a rant spree

I really like simple examples.. for my IDEA Ruby plugin I just looked into JFlex.. here's what they offer you as "A simple example" :)

No. I don't want to be mean here. And yes, in a way it is a simple example. Compared to a full-blown language specification. But consider the whole context again. The past two days all I tried to do is add some simple Ruby syntax hilighting to IDEA. How complicated can that be? How complicated should that be?

That's all I'm saying.. I mean.. You know?

tfdj

Update: IDEA Plugin Development

I've spent most part of this easter monday working on basic Ruby syntax hilighting for IDEA. (See the previous posts for some more context..) I've got a simple lexer and the "surrounding" classes finished in a "proof-of-concept" way.

The funny thing, however, is,that "surrounding" means about 10 classes.. Anyway, I'll check out some more of the JavaScript example code provided by JetBrains. Quite useful to get you started in the world of "We don't need no useful APIs".. :)

What becomes quite apparent quickly is that you should probably use something like "flex" to generate your lexer code. But I wonder how IDEA handles the XML filetypes stuff.. I never worked with anything remotely compiler-related (I mean yacc, etc, not the compiler itself.. :). So I have to check out flex next..

tfdj

IDEA (Not a) Rant Part 2

Here's a quote from The Basics of Plugin Development for IntelliJ IDEA:

A more complex example for getting a container inside the event handler is presented below. In this example, the DataContext class is used for passing context references for the considered action. This class deserves special attention, and we will consider it in detail in another article devoted to actions and passing context parameters principles.

And here's some following example code from this article:

public class MyAction extends AnAction {
public void actionPerformed(AnActionEvent e) {
DataContext dataContext = e.getDataContext();
Project project = (Project)dataContext.getData(DataConstants.PROJECT);
Module module = (Module)dataContext.getData(DataConstants.MODULE);
}
}

In context of my previous post, this is just another example of what I mean when I ask for more declarative APIs. Sure, I understand certain reasons for using "identifiers" to retrieve Objects from some kind of object container. And it may very well make absolute sense for the JetBrains guys to do it this way. But expose such an API? To a potential external plugin developer? Smells strange, doesn't it?

And what would the problems be when offering an alternative API using a more declarative style like for example this:

... {
project = dataContext.getProject();
module = dataContext.getModule();
...
}

Of course, you can't have a million getThis, getThat, etc methods in the DataContext API. But is this a valid argument against a more declarative API? Or an argument for an ID-based "query-API"? I don't think so. All it means is, that something is not they way it should be.

The question should probably be more like: How can I separate the DataContext thing into sub contexts? Or can I provide specialized contexts depending on the kind of "plugin component part" I'm currently working on.

Enough of this..

There's something above all that.. It has to do with arguments "Why Ruby is better?" and the like. It runs along these lines:

If you're used to coding in a more dynamic language, you probably come to like how you can implement a lot of things with very little code. (Let's leave all strong-typing related matters aside for now. They don't matter here.) In this context I kind of hate Jave. Obviously.. :)

BUT: I still think arguments like "Java + IDEA" vs "Ruby + ???" saying basically that with Ruby you're pretty much stuck with typing everything yourself are.. well.. valid in a way. Not so much as to count number of key strokes and compare them. But like.. with a nice Java API and a nice Java IDE, the IDE can actually "guide" you through what you want to acomplish.

In Ruby (for example) you're pretty much stuck with reading docs (remember the days of JDK1.1 and 1.2? I do.. :) and/or trusting your guts. Of course things are not as bad for Ruby as they may sound here. Writing Ruby is a lot of fun, and you're guts are right a lot of times. And a test-driven approach helps a lot to keep a nice development speed in Ruby.

But Java, with the right APIs and the right IDE, can make 90% of the coding work a real breeze. You still write a lot more code than in Ruby, no doubt about that. But you proabably have to, because of some limitation that's still present in the Ruby world, or some legacy argument forcing you to use Java. But with appropriate APIs that help the IDE to guide you, Java coding isn't that bad.

This is my problem with looking at the pluging development stuff offered by IDEA.. You know what I mean?

tfdj

IDEA Plugin Development

Subtitle: PicoContainers, Decoupling and other things I don't know anything about.

Alright, in a really weird way this post is a perfect candidate for this 'In a world gone mad' blog. Here's why..

Besides other, probably more important things, frameworks like PicoContainer try to make decoupling easier. Maybe a too simplistic description. But let's focus on the resulting "APIs"..

You try to avoid too tight coupling. You rely on alternative mechanisms like for example singleton objects like "ApplicationManager" etc. You access the objects you need - when you need them - through the associated singleton classes.

Which probably is fine under certain circumstances. But does it really make things easier? It surely makes the 'top level interfaces' easier. Have a look at for example the "ApplicationComponent" interface provided by IDEAs OpenAPI:

public interface ApplicationComponent
{
String getComponentName();
void initComponent();
void disposeComponent();
}

Easy enough. But what does it tell you?

Here's what I mean: Why is there no "anchor" object part of method signatures? Why is it better to have to read the (quite extensive) documentation to find examples on how (and reasons why) to use for example the ApplicationManager class. Looking at a somewhat more sophisticated plugin like GroovyJ you are faced with all the beauty of this "system".

Don't get me wrong.. I don't mean to sound too negative here. I think taking everything into account the JetBrains guys did a great job! And of course it's quite a hard problem itself to figure out what this before mentioned "anchor" object would look like.

What I really mean to say is this: If a system gets complex (complicated?) enough to make you long for a "dependency injection thing", wouldn't it then be a good time to stop for a minute, and try to look at your problem from a different point of view? Maybe looking for alternative solutions? Shouldn't there be an easier solution? A more expressive, maybe more "declarative" API possible? An API that guides you through the development?

OK. Sorry for this - not really! - rant. I don't know too much about component containers, dependency injection, etc. And I only looked at IDEA plugin development for a few hours. And I haven't worked on projects as big as IDEA must be.

It's just that sometimes.. you know.. I feel lost.. uncomfortable.. you know.. In a world gone mad.. :)

tfdj

IDEA and Ruby

After reading this post yesterday, I started looking into 'extending' IDEA. I never had to do this before. I was quite happy with what IDEA offered me. (And with all my Ruby coding right now, I'm pretty happy with any small text editor - as long as I can configure it to support my shortcuts.)

Well.. On a recent project I implemented a J2ME slideshow framework. It used some Ruby script to define the slideshow and a simple Ruby compiler to create the J2ME code from it. I used JRuby for testing, Ruby for 'driving' the build.

Anyway, it never really occurred to me that there is no good support for Ruby in IDEA. Well, it was good enough for me. (Update: What I mean is that I never had a problem with the limited support in IDEA.) I had my "Ruby Script Files.xml" which made IDEA aware of the fact that .rb files contain some kind of code. It hilights comments and strings properly, as well as some keywords. But there seem to be some weird limitations. Not all keywords work.. Funny enough this never bothered me.. :)

Out of curiosity I started looking at what the Codehaus guys are doing with the GroovyJ plugin. First impressions: WTF!? I guess it's not so much the Codehaus guys.. it's more about the complexity of the IDEA API or more precise the 'possibilities' of IDEA.

Now I wonder: Shouldn't it be easier to add simple support for a new filetype? Like the XML filetypes if they would work properly?

I find that quite interesting. I hope I'll find some more time to look into this a bit more..

tfdj