DM Smith wrote: > Chris, given this I don't think that it serves much purpose to put > this into a module. > > I see two advantages in encoding this: > 1) It is straightforward, much simpler and much smaller. Which will > translate into very fast (no I/O).
It's not entirely straightforward (in my experience). The individual code parts can be of variable length. A particular letter could stand for one thing in one context, another thing in another, or just be part of a longer abbreviation in another context. There's also the issue of our not currently having any facility for virtual modules like this. I did some test code a while ago to produce a virtual commentary module from the current Bible's notes (i.e. all of the notes from the currently selected module show up in a special tab of the commentary pane). But that was all BibleCS-specific and we would need to re-implement something sensible in the API. (And we might want to think about it a little before leaping right into implementation.) Then again, a nice virtual module framework would finally let us do things like virtual commentaries from Bible notes, wdiff modules, etc. A module also has the advantage of being releasable today--as opposed to whenever the next library rev goes out. But I do think library code is easier to maintain than modules are. A module also brings with it lots of nice features to which we are presently accustomed. With a module, we can get a list of keys (since it's a static, finite list). If we do this algorithmically, I don't know how we would populate the key listboxes. With JSword, since I believe there's not even a facility for key input with LD-type modules, I don't see how this would work at all. Modules also have the feature of key linking, with which we could go ahead and build the TVM codes (currently present in some modules) into the module. TVM codes couldn't even be decoded algorithmically, so facilitating them would require a giant lookup table. (But TVM shouldn't be a big factor, since I plan to phase them out, going forward.) > 2) It can readily be internationalized. (Which in JSword would be via > property files.) > > To me the second is the greater gain. I had considered this, but to me it's really not of much benefit. It produces a bit of extra burden for translators (and a burden that requires somewhat specialized knowledge). But fundamentally, there are very few English terms in a morphology module--mostly just ordinal numbers (first, second, & third). And we could change those to numerals (1st, 2nd, & 3rd) to make it a little more transparent to a non-English-speaker. More importantly, if you can't understand the morphology when explicated in English, you probably can't understand the terms in your native language either. It's not that there's no benefit to internationalizing the morphology. It's just that I don't see there being much benefit. If you like, I could just translate the whole thing back into Latin, where it really belongs. > My Hebrew is extremely rusty, but I hope that this would require very > little addition to satisfy the language differences. Perhaps if one > (i.e. you) could map the OT morph codes in the KJV to the appropriate > entry in this new morphology, then one (i.e. me) could modify the > KJV's OT to use these new codes. Sorta. Hebrew has a vastly different morphological system from Greek. (Afro-Asiatic and Indo-European, if related, split so long ago that we're not really certain that they're related.) I do have something in mind for a Hebrew morphology, but it's not quite ready for sharing in public. I do want to address those TVM codes in the OT... fear not. > A third gain is that our (I know I said two) would be that it would be > less likely to be taken by other projects. It seems that our modules > find themselves in all sorts of projects. Maybe "they" get them from > the same sources..... Indeed... this one I've found in the most interesting places.... :) But it does say it's public domain, and I'm not that concerned about people stealing one of our most uninteresting modules. > If you would provide a Perl parser, I would find it very easy to > convert that into Java. If only I still had it.... I wrote a Perl parser for the currently released module, but that was years ago. Now I just have a Perl generator that algorithmically determines all possible codes and generates the code plus its explication simultaneously. Do any of these points change your leanings? I'm really not convinced either way--but keeping a (real) module sure does seem like the easy path. --Chris _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
