<div dir="ltr">Hi Jaak,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 6:24 PM, Jaak Ristioja <span dir="ltr"><<a href="mailto:jaak@ristioja.ee" target="_blank">jaak@ristioja.ee</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div><div class="h5"><br>
On 18.03.2014 08:43, Chris Little wrote:<br>
> We've got quite a few classes in Sword that essentially duplicate<br>
> code found elsewhere in Sword, with minor changes. The module<br>
> drivers are a prime example.<br>
><br>
> Specific examples include RawText & RawText4, RawCom & RawCom4,<br>
> zText & zText4 (new as of today), zCom & zCom4 (new as of today),<br>
> and RawLD & RawLD4, each pair of which differs in that one member<br>
> uses a 16-bit value to store entry size and the other member uses a<br>
> 32-bit value. (The 16-bit sizes permit entries up to 64KiB; the<br>
> 32-bit sizes permit entries up to 4GiB.)<br>
><br>
> There are also the pairs RawText & RawCom, RawText4 & RawCom4,<br>
> zText & zCom, and zText4 & zCom4, each pair of which differs very<br>
> little.<br>
><br>
> My proposal is to collapse the above classes into three classes:<br>
> RawText, zText, and RawLD<br>
><br>
> Each of these classes would support entry sizes of 2, 3, or 4<br>
> bytes (16-bit = 64KiB entries, 24-bit = 16MiB entries, 32-bit =<br>
> 4GiB entries). Internally, the classes would always store sizes as<br>
> a uint32_t, but would serialize as 2, 3, or 4 byte size integers,<br>
> depending on the parameters passed to the constructor. This will<br>
> necessitate changing many of the class method signatures to accept<br>
> uint32_ts instead of shorts & longs.<br>
><br>
> Similarly, the classes zVerse & zVerse4, RawVerse & RawVerse4, and<br>
> RawLD & RawLD4 would be condensed into zVerse, RawVerse, & RawLD<br>
> capable of reading files with 2, 3, or 4-byte entry sizes.<br>
><br>
> This would not require changes to existing modules. A RawLD4 module<br>
> will still work, but we'll use the RawLD driver to read it and<br>
> parse the '4' form the end of the driver name to determine that we<br>
> will read 4-byte entry sizes.<br>
><br>
> RawCom, zCom, & SWCom classes would then be derived from RawText,<br>
> zText, & SWText respectively. Maybe we can even eliminate the *Com<br>
> classes and simply add a member variable to indicate whether to act<br>
> like a commentary or a Bible.<br>
><br>
><br>
> Advantages of this proposal include all of the things that come<br>
> with reduced code duplication: Less code, reduced API complexity,<br>
> smaller library size, etc. Greater consistency, without having to<br>
> page through half a dozen distinct classes to keep code<br>
> consistent. Bugs only need to be fixed in one location instead of<br>
> many. Whatever else makes DRY practices better than WET.<br>
><br>
> The method described also makes it trivial for us to add the<br>
> 3-byte entry size drivers, which should be enough for anything<br>
> practical (up to 16MiB per entry). And down the road, we could add<br>
> 5-byte entry size support with ease for entry sizes up to 1TiB.<br>
> (No, I'm not suggesting that.)<br>
><br>
> If you're wondering why RawGenBook & zLD are left out of the<br>
> proposal, it's because they both use 4-byte entry sizes already and<br>
> no 2-byte versions exist.<br>
<br>
</div></div>Good idea! But I'm not sure whether passing such an argument to the<br>
constructor is a good idea. I'd rather use templates and type traits<br>
for this if we only want to support a few cases (16, 24, 32 and maybe<br>
40 bits).<br></blockquote><div><br></div><div>As I understand it, this configuration is coming from the conf file at least sometimes (and maybe always). That sounds to me much more like a property is needed, not a type trait. Does that make sense?<br>
<br></div><div>Jon<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Blessings,<br>
Jaak<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (GNU/Linux)<br>
<br>
iQgcBAEBAgAGBQJTJ/S4AAoJELozJlbjIn79gM8//2VgFdrTWD8L2YXGlOt2BGZp<br>
VRzV+FzNlcuKMYBxSbbyVes0px4MePZdlWfiIyBclRtlZOkHsEe1X80Cmz/S/YKk<br>
g0Krb40d2qntUPb4Qy3ap7tqJneMyfkp+SLTmCCf7L85kbitcg4kHhvBZVoLJf3+<br>
/f4Nyvu0EerjytHfSdM+Zia4BYaFnEGfmyU9oRl3o7EvsKI++08dyZqqGwFy6h37<br>
WvBCrcbCXLoaEHuQTYnGR4g6973weuMI87dSVcQgS+JR9mD/vmTMtmFefPtFCpWS<br>
5nSm6jMykhDJt1qG+Kpe9gcmzsKkkHTVgj1z7xNceiCcVgsS6Ks72ES0v0AvrsZ4<br>
7WMRPvsQOwwf1XI6jTMeCpRFN3TXx/aNmTUpslGEVJE0JdBvqz4V2TSWPmG6AJHW<br>
/z0XiStljg8y3gjzgmVv4WzedDRLFduUyxnAtb5g8+2YmVt82XzbC3hKxJayZi1V<br>
RwSq4h/NjHPzqNgLs7z7mgnChPz963OFG7o0/L/6X+QYlDvkU4bATiIjmGEuDtEG<br>
2rmsjS+03Aj9CsfPO7AAvgSjFuvh3/aW3wwclzZnrAFAubkLoHIrBJux98ittMdt<br>
UWXxy1NXbqOZQI9AqohU3xnq2MsC+AjInEedjZoNol+lDHYP6tDDvxSQqDSjGT1u<br>
xoBLR7+ymxHq3arufIrzW4xt1X2WYRkUcceaVKzXE41sMRZKQlgbdTGxt5JWcFzq<br>
YozFjR9EdIqIRNUGdmdub3/a65749VsyokoApkJ+KW/NRAdc+749pwfZ0nSGRYo/<br>
OjnJqaDAgR8Pirc6p+m2iLy7EYvcdbXLHZGsRGr8uW6khc8d7XT5OpispjuP56jg<br>
BMMPyZzPGqygTcjGD3age6WGVwUh1wJf9N+mlZwjjbsKIPOTpzSD1v65XTiWe7fo<br>
4RivUaJ8lqFYzOp0CqwC5Cd7DHmA6vhf0JJoYg4UHJhXPo9m++NcEIEYqADmWLS9<br>
lDjb+TxrA9l8SgyT2OPNBIpmUKUmV1zT/8VWjWp4T588ZeS0Sp6TFFS2g41NYUYo<br>
hcdafx0hnORrdo7KNLI+qdS5ajVvuqfJAwLTrfOJc9WJJKFQsufDaMqdE8xuMlIU<br>
yXP27R7a6lvuMP96xa0Xj2+s0EcUNeeEWGRC4CRi/FA+mTcIJZGdYAKbeggxeNsC<br>
pedrIK6uFJVqQCCmHvfNDGF3ZleSC2MJK4hwTrJmjVnQMOO8AO7mXYFVq/mDGQ70<br>
rABVuRKPBVsycZlEggLGv4Q5eZ7iXQmXt2N+eDMgCICLNu44VPXQBvbBKnMxbvRT<br>
3vmcihB8reR9jRO2NKB9DfKKVV0WvFJrU+S3Z3KrhHxrBVS7Dw104NAMvNBTU2sY<br>
+VlJUXV745/43gOBsiTbUWRTHwRtijbjLeqri24Fz9pdh5QxSDo+akE2iN4cgNPF<br>
NILKU4pWZ53OA6eIYwbAMWY/l5npOh266+fNPlGmK0t/dSHlkEdttGhS69nnRIXY<br>
odwujEImWDhCPInCw0jVJ5pss9j9TNSEGnY5DdN7CmUyyATtFKbOE1V70cH01DUt<br>
gfxHqbEtyeoxPo7+m6LB4xriNlKYt6RlmWVTPPtIdzx6vLepoJuYJ+7HKHJWl/st<br>
KAdeLyFUg6kjpYbUBB+JsFsX8lY2b+9nSFB8n3mCPCDoGwNAco++nlZ/AmgykprC<br>
o+GLPDhrwqx7MCiXCvj1+RfmCR5HDjLA4IlTPDhPOnYBWUZt55evFEZ4lF0GsGqi<br>
Ok2269aPNc5loJLZBunSEVFUmdz6RpBngIFLHgOmfV9BgCH4L7KyaUPy7JbekI4Q<br>
gFQfIRS9hmxgFRjz8FGOI6L50HJpv8kFG8iy4ibtL3lIvXIHg6iHO1G+FRig9eey<br>
fs1Ge3A7eDysiWA+54oqa2x+eVhqdYIeZzNRnotBT/v+UHYOQ/K3dGU3+0zX74Gi<br>
RVO51/5g+gx/ZNW2CXZJZAPlN7U7spXjtnaOmAmG8NFXK+ezTgxY7SElQZYbVZgT<br>
NLWZ9SBj4Ykbey0AymoYeSLNFFCp3kvtSaE/vahxgvZsrk7oc6tTCIh0OM7hdzwe<br>
xWJjviTDcU9FY+eYkl4RH4R9KplLdOdL5CrUJ+QX2YDW+0UUTP5zD+z5BuOm4NoJ<br>
d8NWywFljMjgfu9bj0EW+ZsWJvz7T9s2EsoEvosukQjzC6cR9GgIhkA2QSre3g93<br>
6e758bLZSbbRLyBPjsWYoSzpYbfGpHcqFTGN93+GjlQX0oSg6V+/O4GwuqC4Ztq+<br>
Ck3bqnMviTrOyEqS1UQVOBbDuu3jnho8TaPx5fY82G+W/3rhw3Iq0FqVas5L2Ey0<br>
GG6Gv/topXODsf2KhhmheD+WR3Ubvd0kFGBzaNQMwux7eR7cJPU8y2mGmFHTas21<br>
YuEE+nG5LLL6dnDYKoRxYrBgVm49bvny9e5dlYJqhMiKNAG/afraSvzRXQhyLrP1<br>
ddu5PP6lzqSW0EV62v15BcZaOtnzB8Ig1mWe/qrFIJUFfskXhfSDbfkC2HjyuGC/<br>
lCPGobscnSqx5EszWVuTadKKVcXtNsEaBbXT0p73+WzxGgIt/lMEKUq4u8n+LKlM<br>
5KNfNV8csxkvZRZr5UGwEwm+G1xIb+cy4w73B/Ld2paOwUWGfcOl1fwVuua67gfB<br>
3OIc4P+JHwwGwppcKecPOX/UvjLpLrqb1FNOrmcdcfSnHXaMgnPdRsSB7hR6uuFc<br>
9TqqZv7ml5T7r8SMd8Ji<br>
=k7Vn<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br></div></div>