My development laptop is still at the shop--a shop who is about to receive an untimely, unpleasant phone call if this continues. You know who you are.
SharpDevelop2
Things I plan to have a whack at when my laptop is back:
- #develop2 addin: I wanna gank the feature in Eclipse that highlights all references to a variable when you put your caret over it. EG, you move the caret over the variable "cheesecake" and all instances of cheesecake are highlighted in the editor.
- #develop2 addin: quick rename refactoring. Basically, instead of using the rename menu, I want this addin to monitor the names of class definitions, so when you're renaming one, all instances of that class name are renamed elsewhere. Really, that's what you were going to do /anyway/, right?
So far I've been playing with the #develop2 API in regards to its refactoring stuff, and the API, while robust, isn't very convienent to use. In other words, it's not really all that task oriented. This'll probably chance in the future, since pretty much everything else I've encountered is nice and easy to work with.
In my prototypes I can already see that I'm going to have to cut/paste the same block of code into both addins--it's the code that finds all references for the word at the current caret position. There's simply no other way to do it, and once people start exploring the refactoring ability of SharpDevelop2, I think it's going to become a very common idiom.
The problem with the current model for, say, finding references, is that it requires you to go through the parser API first, then use the result from that in the refactoring API. Not only that, you have to -- by hand -- determine which overloaded "find references" method to call, because there's no convienence method that simply accepts a base "ResolveResult" and correctly looks up the type hierarchy to determine if you're looking for a reference to a class, a local variable, or a class member.
So, basically you have to determine wheither the base ResolveResult is actually a type resolve result, a local resolve result, or a member resolve result, and then do the cast by hand before calling one of the find references method. That. Is. The. Suck. It's also code I'm going to end up duplicating in both addins. Ow.
Most of these issues could be fixed with very small patches to make the API "addin programmer" friendly, but since they'd most likely be over 8 lines, you'd have to sign their, uh, something-something-something license agreement. Not really worth signing paperwork just for a simple 20-line convienence method. Don't have a fax machine anyway.
Someone migrates away from C#!
This isn't something you see every day.
Foreward: Irrlicht is a very popular 3d engine, noted for its simplicity but very robust abilities. It's very competitive with Ogre3d, since Irrlicht makes up for what it lacks with a dead-simple API that lets you do whatever the hell you want.
Anyway.
The Irrlicht dude was writing an editor in C#, but suddenly decided to switch to C++ for some reason. When I read his reasons why, they seemed a bit weak--took me a couple of seconds to realize he was probably writing his C# code how he writes his C++ code, which is always a disaster--I'm assuming this, anyway, because his comment doesn't make much sense if you think of it any other way. He might have meant something else, and hit one of those purdy Language Barriers that crop up so often on the Internet. Interweb. Excuse me, Web.
He's surprised that the C++ version is faster than the C# version, and is left asking himself why anyone should use C#.
All in all, I think it's a pretty flawed comparison that he does, but still it's very interesting to read.
No comments:
Post a Comment