| 207 | | doesn't have to be used if prior coordination happens between developers. |
| | 207 | doesn't have to be used if prior coordination happens between developers; |
| | 208 | moreover, this namespace is likely to be used even by the main Muldis DB |
| | 209 | developers to experiment with possible extensions without tying up a "good" |
| | 210 | namespace for them. |
| | 211 | |
| | 212 | =item C<MuldisX::DB::Simple> |
| | 213 | |
| | 214 | The Muldis DB native API, as presented by the C<Muldis::DB::Interface> |
| | 215 | roles, is quite verbose. It by default just accepts Muldis D code |
| | 216 | formatted as vanilla Perl Hosted Muldis D tuple and relation values that |
| | 217 | are of Muldis D system catalog data types. While this format is simple and |
| | 218 | yet very expressive, unambiguous, easy to validate and translate, it tends |
| | 219 | to be non-dwimmy and require a programmer's intent spelled out for it, |
| | 220 | which increases code size an order of magnitude over a dwimmy equivalent, |
| | 221 | and also all expression trees have to be decomposed into a tagged list of |
| | 222 | tree nodes (a tuple or relation value is always a fixed composite depth |
| | 223 | rather than N-depth), which HLL programmers may find less friendly. |
| | 224 | |
| | 225 | The C<MuldisX::DB::Simple> module is an abstraction over I<Interface> which |
| | 226 | adds a considerable amount of dwimminess to it, and adds support for |
| | 227 | writing expressions as actual N-depth trees, and adds a considerable amount |
| | 228 | of huffmanization and common task shortcuts; this greatly reduces the size |
| | 229 | of the Muldis D code that programmers would actually write on a day to day |
| | 230 | basis, and make it more resemble other high-level languages. |
| | 231 | |
| | 232 | Unlike other such modules, C<Simple> is written by the creators of the |
| | 233 | Muldis D core itself. Some of its concepts may make their way into the |
| | 234 | core roles as an additional API option, but meanwhile they are in the |
| | 235 | separately distributed (under the same LGPL license) C<Simple> where they |
| | 236 | can be experimented on more freely without unduly complicating the core |
| | 237 | (and encouraging competition). C<Simple> is a top priority for |
| | 238 | implementation, as it should help to test the core as well as help get the |
| | 239 | initial user base off the ground faster. |
| | 240 | |
| | 241 | In regards to what huffmanization and common task shortcuts are provided by |
| | 242 | C<Simple>, a lot of influence should be taken from the variety of existing |
| | 243 | C<DBI> or SQL wrappers on CPAN whose mandate is to make them simpler or |
| | 244 | more dwimmy, such as C<SQL::Abstract>. In fact, while full emulation isn't |
| | 245 | promised, C<MuldisX::DB::Simple> may provide quasi-clones of several of |
| | 246 | such module's interfaces, so to help migration of people using them. As |
| | 247 | with those other modules, C<Simple> will provide pass-thru when it doesn't |
| | 248 | have any special treatments for things that programmers want to do. |
| | 249 | |
| | 250 | In the longer term, C<MuldisX::DB::Simple> is deprecated (at least under |
| | 251 | that name) in favor of better solutions, independent or otherwise. |