From: David Masover on 26 Feb 2010 18:02 On Thursday 25 February 2010 02:23:33 am Charles Roper wrote: > I am doing a bit of research for a project I am helping out with - a > text editor - and the following question has been asked: what would your > dream API look like and be capable of? Obviously, the API will be > scriptable via Ruby. First, make a low-level API. Then, join us in trying to build a "dream API" on top of that. I'm not sure what it would look like, I have no idea what it's like to hack on a text editor. I'd say, let's look at the capabilities you have now, build that low-level API, and document everything, then we can start to talk about how you might improve it. As for that higher-level API... You may want to brush up on some Ruby idioms. For example, Ruby tends to support the more flexible idiom of returning an object representing some sort of handle in a longer operation (like reading a file or looping over a list): file = open 'foo' line = file.readline file.close That's needed in order to have full functionality, but we also expect tricks like this: open 'foo' do |file| file.each_line do |line| ... end end (Note: The 'file' variable is identical in both cases, it's just that the loop automatically handles closing the file for us, probably ensuring it happens no matter what kind of exceptions are thrown, etc.) The same works for generating output. Look at Builder, Erector, etc, for some examples of how that can look. So without knowing your editor's capabilities in detail, and without ever programming an editor, I don't really know. You'll at least want to provide a low-level API, in case people disagree with your approach, or in case someone else comes up with a better idea. But if you want a higher-level API, something that'll blow us away, something like Hpricot but for text editors... That takes artistry.
First
|
Prev
|
Pages: 1 2 Prev: WWW deprecation notice in Mechanize Next: Help on algorithm to calculate combinations |