<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html>
<head>
<meta name="Generator" content="Zarafa WebAccess v6.20.4-14107">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<title>Convenience over extensibility? Or: How to build on top of hu.dwim.rdbms?</title>
<style type="text/css">
body
{
font-family: Arial, Verdana, Sans-Serif;
font-size: 12px;
padding: 5px 5px 5px 5px;
margin: 0px;
border-style: none;
background-color: #ffffff;
}
p, ul, li
{
margin-top: 0px;
margin-bottom: 0px;
}
</style>
</head>
<body>
<p> </p><p>>> While the sql reader syntax e.g. [select * table] is convenient for humans<br />>> it doesn't allow for being used by other functions or does it?<br />><br />><br />>(read-from-string "") as a last resort, otherwise it reads into a CLOS<br />>based AST anyways and that you can construct programmatically.<br />><br />>note: the SQL reader and AST stuff is on the TODO to be moved into<br />>hu.dwim.quasi-quote and rebased on its infrastructure. but it's not<br />>high priority, and wouldn't change anything conceptually...<br />><br />><br />>> In my opinion such a sql reader syntax is nice to have but not being able to<br />>> extend the software<br />>> through the use of functions is disastrous in my eyes. I have the feeling<br />>> that we create two camps here, one the developers<br />>> and the other the users. Personally I don't like that distinction and would<br />><br />><br />>it's a library for developers, there are no two camps. it's only developers....<br />><br />><br /><br />I made a rash judgement here, sorry.<br /><br />>> much prefer to make the possibility of extending<br />>> the software through the use of functions as easy as possible for the so<br />>> called "user".<br />>><br />>> With that in mind I find myself using internal function and classes from the<br />>> hu.dwim.rdbms package<br />>> ( e.g. sql-and, sql-sequence-nextval-column, sql-identifier,<br />>> sql-all-columns, sql-= )<br />>> and writing wrapper functions for it e.g.<br />><br />><br />>we didn't put too much effort into deciding what should be exported<br />>and be part of a long-time API, and what isn't. but while (not) doing<br />>that we were on the conservative side...<br />><br /><br />Maybe we should separate the sql reader syntax "stuff" from the rest, so we have one more package to maintain? :)<br /><br />Please make sure that you expose a "relative" low level interface that can be accessed programmatically<br />and is as expressive as necessary so that a great variety of extension can be build on top of it.<br />I find it somewhat puzzling that the sql reader syntax was not build on top of such an interface.<br />After all, the sql reader syntax should be just an extension?<br /><br />If I think about I often work in one package despite the fact that two would be warranted just to get things done.<br />Maintaining packages is hassle. So maybe not so puzzling after all ...<br /><br /><br />><br />>> What do you think about what I just said. Did I go wrong somewhere?<br />>> And if the above is really an issue, any ideas as how to handle it?<br />><br />><br />>define your own convenience functions? if they seem to be generally<br />>useful, propose an extension (but to spare some time, the naming<br />>convention you use in your functions will not go though :)<br />><br /><br />Yes, I will stick to my convenience functions and adapt to your future changes.<br /><br />As for the naming convention I'm more than willing to compromise and there are many ways for dealing with this<br />e.g. emacs abbrev mode, graham's abbrev macro or just inline functions for personal use.</p><p><br />Don't worry, I never expected my naming convention to go through.<br /><br />><br />>> Right now I did create another system and package called<br />>> hu.dwim.rdbms.oracle.ext for things like the above.<br />>> (The names above are not carved into stone tablets. I often change my mind<br />>> before I settle for certain names and yes,<br />>> often the wrappers seem unnecessary but I don't want to change the package<br />>> definition of hu.dwim.rdbms<br />>> and/or prefer shorter names.)<br />><br />><br />>that's a good compromise and leaves you the freedom to use<br />>names/shortcuts you prefer. even if such utils were provided by the<br />>main lib, it would not please everyone... so the way to go is to<br />>provide a preferably complete skeleton of functionality using<br />>descriptive and sometimes long names, and let people do their<br />>shortcuts if the need be.<br />><br />>we stick to long names (and use fuzzy completion in slime).<br />><br />>-- <br />> attila<br />><br />><br /><br /> --<br /> chris<br /><br /><br /> </p>
!DSPAM:4cd40a5848581824115346!
</body>
</html>