Re: [std.database] at compile time
Good point. I wasn't thinking of a tool to validate arbitrary SQL statements, but one that could validate a D model's correspondence with the database schema. Presumably the queries would be generated by the library. what i like to see here are both parts - staticaly checked (if possible) for faster development - but also runtime checked (maybe in form of an check-mode) for example: you've got a varchar(12) field - how many times have you seen an check for the inputsize not exceeding the 12 chars? or datetime, etc. not all databases got the same range for special type values but something like that could be to database/version specific
Re: [std.database] at compile time
On Fri, 14 Oct 2011 23:58:45 +0200, dennis luehring wrote: >> One approach would be to write a separate tool that connects to the >> database and writes out a representation of the schema to a source >> file. At compile time, the representation is statically imported, and >> used to verify the data model. > > what about data/fields that don't comes out of the model? > > for example: > > select >name_length_add_1, >count(*) as counted > from >( > select > (len(p.firstname) + 1) as name_length_add_1, p.* > from > persons as p > inner join members as m on p.firstname == m.firstname >) as blub > group by >name_length_add_1 > > how is the "counted" field or "name_length_add_1" staticaly verified? > > people tend to think that sql is just simple table querying stuff - but > thats not, not in the real world Good point. I wasn't thinking of a tool to validate arbitrary SQL statements, but one that could validate a D model's correspondence with the database schema. Presumably the queries would be generated by the library. Best, Graham
Re: dmd.conf change for Ubuntu 11.10
On Fri, 14 Oct 2011 13:05:04 -0700, Justin Whear wrote: > Changes to gcc or ld in Ubuntu 11.10 require a small addition to prevent > linker errors referencing librt. "-L-lphobos2" needs to be added to > DFLAGS before "-L-lrt". I spent a long time trying to figure the problem > out before I realized that gcc was tacking on a -lphobos2 to the END of > the command (after the -lrt flag). > > This page: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition may > explain the behavior, I'm not sure. The relevant text: Ubuntu is changing the way it handles shared library linking for the Natty release. (Similar changes are being discussed for Debian.) ... The --as-needed [on by default] option also makes the linker sensitive to the ordering of libraries on the command-line. You may need to move some libraries later in the command-line, so they come after other libraries or files that require symbols from them.
Re: User packages/libs (Was: Just starting out)
On Fri, 14 Oct 2011 12:30:59 -0700, John Arrizza wrote: > Just curious... any plans to have an official user supplied set of > packages or modules ala CPAN or ruby gems etc.? > > Having a central repository of these kinds of things would probably > increase D popularity. > > John > DSSS was similar to that goal. Dsource is a place to host projects in one place. And someone is working on something new.
Re: eating inout dogfood
On 2011-10-14 20:05:09 +, "Steven Schveighoffer"
said:
I don't think the compiler will auto-convert someTemplate!(inout(V)) to
e.g. someTemplate!(const(V)). Does that work? I know that for
instance, I can't do this:
struct S(T)
{
T * x;
}
S!(int) ptr;
S!(const(int)) cptr = ptr;
So I wouldn't expect the compiler to do the above translation either...
Perhaps you can add this to the struct:
void this(U)(in S!U other) if (__traits(compiles, this.x = other.x))
{
this.x = other.x;
}
If that works, maybe a similar approach could be used to solve the
problem with inout: if you can construct the requested type from the
provided one it get converted automatically at the call site.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Statically forbid string ~ size_t ?
On 14/10/11 12:23 PM, Steven Schveighoffer wrote:
On Thu, 13 Oct 2011 18:34:35 -0400, Don wrote:
On 13.10.2011 23:07, bearophile wrote:
I think that int+char is acceptable in D, but string~size_t is not
good. I think this is bug prone (especially given the expectations of
programmers coming from other languages). So I suggest to statically
disallow string~size_t. string~char, string~dchar, and string~string
are of course OK.
So far I have written no enhancement request/bug report on this
because I am not so sure...
The problem is things like:
int i;
string s = "0x" ~ ('0' + x);
since char + int --> int.
string s = "0x" ~ cast(char)('0' + x);
Problem solved.
-Steve
Agreed.
I don't think it's worth violating fundamental principles for the sake
of a minor convenience in relatively uncommon situations.
Honestly, I'd like to get rid of implicit conversions altogether, but
maybe that's just me...
Re: eating inout dogfood
2011/10/15 Steven Schveighoffer :
> I don't think the compiler will auto-convert someTemplate!(inout(V)) to e.g.
> someTemplate!(const(V)). Does that work? I know that for instance, I can't
> do this:
>
> struct S(T)
> {
> T * x;
> }
>
> S!(int) ptr;
> S!(const(int)) cptr = ptr;
>
> So I wouldn't expect the compiler to do the above translation either...
IMO, for the purpose we need covariant/contravariant template type
parameter like Scala.
Kenji Hara
Re: [std.database] at compile time
On Fri, Oct 14, 2011 at 11:58:45PM +0200, dennis luehring wrote: > what about data/fields that don't comes out of the model? My database.d does this: 1) You can create simple table classes from create table 2) You can do a query into a dynamic object So if you are doing something that can't be statically checked, that's ok, the dynamic object fills in the rest.
Re: [std.database] at compile time
One approach would be to write a separate tool that connects to the database and writes out a representation of the schema to a source file. At compile time, the representation is statically imported, and used to verify the data model. what about data/fields that don't comes out of the model? for example: select name_length_add_1, count(*) as counted from ( select (len(p.firstname) + 1) as name_length_add_1, p.* from persons as p inner join members as m on p.firstname == m.firstname ) as blub group by name_length_add_1 how is the "counted" field or "name_length_add_1" staticaly verified? people tend to think that sql is just simple table querying stuff - but thats not, not in the real world
Re: [std.database] at compile time
Dmitry Olshansky Wrote: > On 14.10.2011 19:13, foobar wrote: > > Andrei Alexandrescu Wrote: > > > >> On 10/14/11 6:08 AM, Jacob Carlborg wrote: > >>> On 2011-10-14 12:19, foobar wrote: > Has anyone looked at Nemerle's design for this? > They have an SQL macro which allows to write SQL such as: > > var employName = "FooBar" > SQL (DBconn, "select * from employees where name = $employName"); > > what that supposed to do is bind the variable(s) and it also validates > the sql query with the database. This is all done at compile-time. > > My understanding is that D's compile-time features are powerful enough > to implement this. > >>> > >>> You cannot connect to a database in D at compile time. You could some > >>> form of validation and escape the query without connecting to the > >>> database. > >> > >> A little SQL interpreter can be written that figures out e.g. the names > >> of the columns involved. > >> > >> Andrei > > > > The downsides with writing a separate SQL interpreter are: > > > > a) No connection to the DB means no way to validate the schema, e.g. the db > > might not even have a 'name' column in the employees table. > > The upside is that you can at least rebuild your app when database is > down or compile it on a separate machine. > > > b) No way to validate the SQL per the exact version the DB uses. E.g. LIMIT > > vs. TOP and also DB vendor specific extensions to SQL syntax. > > c) NIH - implementing your own SQL interpreter when the DB vendor already > > provides it. > > > > oh, well, perhaps it would be possible with D3 once it supports proper > > macros. In any case, such a macro probably would be built atop the DB API > > currently being discussed. > > > -- > Dmitry Olshansky That's just silly, why would you use a validating SQL macro if you do not want (or don't have the environment set up) to validate the SQL?
Re: [std.database] at compile time
Graham Fawcett wrote: >> >> But you still won't be able to verify the columns to the actual database >> scheme? > > One approach would be to write a separate tool that connects to the > database and writes out a representation of the schema to a source > file. At compile time, the representation is statically imported, and > used to verify the data model. > > If we had preprocessor support, the tool could be run as such, > checking the model just before passing the source to the compiler. > > Graham This is actually possible now. I wrote a little CTFE parser for CREATE TABLE... statements, used mysql to dump a db, then used import() to include the dump and parse it at compile-time. I was actually using it to generate classes which mapped to the contents of each table (i.e. a "things" table would result in a "Thing" class which mapped the fields as properties). Obviously you need to keep the db dump up to date via an external tool.
Re: [std.database] at compile time
On Fri, 14 Oct 2011 21:10:29 +0200, Jacob Carlborg wrote: > On 2011-10-14 15:26, Andrei Alexandrescu wrote: >> On 10/14/11 6:08 AM, Jacob Carlborg wrote: >>> On 2011-10-14 12:19, foobar wrote: Has anyone looked at Nemerle's design for this? They have an SQL macro which allows to write SQL such as: var employName = "FooBar" SQL (DBconn, "select * from employees where name = $employName"); what that supposed to do is bind the variable(s) and it also validates the sql query with the database. This is all done at compile-time. My understanding is that D's compile-time features are powerful enough to implement this. >>> >>> You cannot connect to a database in D at compile time. You could some >>> form of validation and escape the query without connecting to the >>> database. >> >> A little SQL interpreter can be written that figures out e.g. the names >> of the columns involved. >> >> Andrei > > But you still won't be able to verify the columns to the actual database > scheme? One approach would be to write a separate tool that connects to the database and writes out a representation of the schema to a source file. At compile time, the representation is statically imported, and used to verify the data model. If we had preprocessor support, the tool could be run as such, checking the model just before passing the source to the compiler. Graham
Re: eating inout dogfood
On Fri, 14 Oct 2011 14:17:09 -0400, Walter Bright
wrote:
On 10/14/2011 4:29 AM, Steven Schveighoffer wrote:
On Fri, 14 Oct 2011 04:43:15 -0400, Kagamin wrote:
Steven Schveighoffer Wrote:
struct cursor(T)
{
T* node;
void popFront() {node++;}
... // usual suspects front, empty, etc
}
This seems like cursor!(inout(V)) might work (V is the element type
of the
container) as the return type for inout functions. However, one of the
major requirements of inout is that it correctly cast back to the
constancy of the container.
try to return inout(cursor!(Unqual!(V)))
This won't solve the problem. I need inout to be on V, not on the
cursor.
return cursor!(Unqual!(inout(V));
I don't think the compiler will auto-convert someTemplate!(inout(V)) to
e.g. someTemplate!(const(V)). Does that work? I know that for instance,
I can't do this:
struct S(T)
{
T * x;
}
S!(int) ptr;
S!(const(int)) cptr = ptr;
So I wouldn't expect the compiler to do the above translation either...
-Steve
dmd.conf change for Ubuntu 11.10
Changes to gcc or ld in Ubuntu 11.10 require a small addition to prevent linker errors referencing librt. "-L-lphobos2" needs to be added to DFLAGS before "-L-lrt". I spent a long time trying to figure the problem out before I realized that gcc was tacking on a -lphobos2 to the END of the command (after the -lrt flag). This page: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition may explain the behavior, I'm not sure.
User packages/libs (Was: Just starting out)
Just curious... any plans to have an official user supplied set of packages or
modules ala CPAN or ruby gems etc.?
Having a central repository of these kinds of things would probably increase D
popularity.
John
Nick Sabalausky wrote:
>"Jesse Phillips" wrote in message
>news:j77s69$1j3d$1...@digitalmars.com...
>> Nick Sabalausky Wrote:
>>
>>> "Jesse Phillips" wrote in message
>>> news:j75t0k$2q6m$3...@digitalmars.com...
>>> >
>>> > I created a cmdln library to help with user interaction, which some
>>> > seem
>>> > to like.
>>> >
>>> > https://github.com/he-the-great/JPDLibs/tree/cmdln
>>> >
>>>
>>> Looks very nice. I have a similar (but probably more basic) thing, too
>>> (just
>>> one function: "prompt"):
>>>
>>> http://www.dsource.org/projects/semitwist/browser/trunk/src/semitwist/cmd/plain.d#L216
>>>
>>>
>>> // -- Basic string prompt --
>>> string input1 = prompt("Type some stuff: ");
>>>
>>> // -- String prompt with validation --
>>> // (failureMsg is optional)
>>> string promptMsg = "Do you want 'coffee' or 'tea'? ";
>>> string failureMsg = "Please enter 'coffee' or 'tea', not '%s'";
>>> bool accept(string input)
>>> {
>>> return ["coffee", "tea"].contains(tolower(input));
>>> }
>>>
>>> // This will *not* return until the user enters a valid choice,
>>> // so we don't need to do any more validation.
>>> string input2 = prompt(promptMsg, &accept, failureMsg);
>>
>> Interesting the similarities. I do provide more specialized functions for
>> some of those:
>>
>> auto input2 = menu(promptMsg, ["coffee", "tea"]);
>>
>> auto input = require!(string, accept)(promptMsg);
>>
>> I haven't provide the option of displaying an error message, but it could
>> go in the delegate you use in require. And I suppose prompt is a better
>> name than userInput.
>>
>
>Yea. I think mine is more customizable and generalized, but yours is more
>batteries-included and ready-to-go (which makes yours very enticing). Maybe
>we could merge our designs and come up with something suitable for Phobos? I
>think this is the exactly the sort of thing that's a perfect fit for
>inclusion in a std lib: Very handy, but for many people not big enough to
>justify adding an external dependency.
>
>> On thing I've been kind of interested in is getting something set up that
>> would allow providing the needed information via a config, args, or at
>> runtime. but haven't done anything with that idea.
>>
>
>That would be neat.
>
>One thing I'd been thinking of adding to mine was an alternate function that
>just waited for a single keystroke (rather than a line of text + Enter). I
>think I once had it working on Tango, IIRC, but then I switched to D2/Phobos
>and couldn't figure out how to use Phobos to wait for a single keystroke w/o
>then waiting for Enter.
>
>
Re: [std.database] at compile time
On 2011-10-14 15:26, Andrei Alexandrescu wrote: On 10/14/11 6:08 AM, Jacob Carlborg wrote: On 2011-10-14 12:19, foobar wrote: Has anyone looked at Nemerle's design for this? They have an SQL macro which allows to write SQL such as: var employName = "FooBar" SQL (DBconn, "select * from employees where name = $employName"); what that supposed to do is bind the variable(s) and it also validates the sql query with the database. This is all done at compile-time. My understanding is that D's compile-time features are powerful enough to implement this. You cannot connect to a database in D at compile time. You could some form of validation and escape the query without connecting to the database. A little SQL interpreter can be written that figures out e.g. the names of the columns involved. Andrei But you still won't be able to verify the columns to the actual database scheme? -- /Jacob Carlborg
Re: Remove macro keyword?
On Friday, October 14, 2011 20:49:13 Alex Rønne Petersen wrote: > On 23-08-2011 15:41, Alex Rønne Petersen wrote: > > Hi, > > > > Would it not be a good idea to remove the macro keyword? It doesn't seem > > like there's anything happening with the AST macros idea anyway, and > > it's an identifier that I actually find myself wanting to use > > occasionally... > > > > Regards, > > Alex > > Any input on this? Especially from people hacking on DMD? > > Reserving a common word like this for no purpose is not very reasonable > IMO... At this point, I think that it is the way that it is, and it's going to stay that way - if nothing else because there's every possibility that a new feature will be added at some point in the future which uses the macro keyword. If we do add such a feature, it probably won't be until D3, but if we have the macro keyword in D2, then there's a greater chance of being able to add such a feature in a backwards compatible manner into D2. Removing the keyword now is just going to cause problems later if we ever want it as a keyword again. - Jonathan M Davis
Re: Inferred enum base types
On Friday, October 14, 2011 20:47:12 Lennart Blanco wrote:
> Hi
>
> When compiling following code with dmd (v2.051)
>
> enum nums { X = 'a', Y, Z }
>
> void main() {
> nums q;
> char w;
> w = q;
> }
>
> I get 'Error: cannot implicitly convert expression (q) of type nums to char'
> for the 'w = q' assigment.
>
> Should'n the inferred base type for 'nums' be char, given that the first
> 'nums' member is initilized with char literal 'a'?
>
> When the nums declaration is changed to:
>
> enum nums : char { X = 'a', Y, Z }
>
> the code compiles without errors.
>
> It seems that when enums base type is allways inferred to int. Am I missing
> something or is it an DMD bug?
I believe that the answer is that there is effectively no inferrence when you
give a list of enum values (rather than declaring a manifest constant), and it
is always assumed to be int unless you declare it to be otherwise.
I would point out however, that you wouldn't want it to be char anyway. You'd
want it to be dchar. Since char uses a multi-byte encoding, you're just
begging for bugs if you operate on individual chars (which is why I think that
'a' should be inferred to be dchar, but that's a separate issue).
- Jonathan M Davis
Re: Remove macro keyword?
On 23-08-2011 15:41, Alex Rønne Petersen wrote: Hi, Would it not be a good idea to remove the macro keyword? It doesn't seem like there's anything happening with the AST macros idea anyway, and it's an identifier that I actually find myself wanting to use occasionally... Regards, Alex Any input on this? Especially from people hacking on DMD? Reserving a common word like this for no purpose is not very reasonable IMO... Regards, Alex
Inferred enum base types
Hi
When compiling following code with dmd (v2.051)
enum nums { X = 'a', Y, Z }
void main() {
nums q;
char w;
w = q;
}
I get 'Error: cannot implicitly convert expression (q) of type nums to char'
for the 'w = q' assigment.
Should'n the inferred base type for 'nums' be char, given that the first
'nums' member is initilized with char literal 'a'?
When the nums declaration is changed to:
enum nums : char { X = 'a', Y, Z }
the code compiles without errors.
It seems that when enums base type is allways inferred to int. Am I missing
something or is it an DMD bug?
/lennart
Re: eating inout dogfood
On 10/14/2011 4:29 AM, Steven Schveighoffer wrote:
On Fri, 14 Oct 2011 04:43:15 -0400, Kagamin wrote:
Steven Schveighoffer Wrote:
struct cursor(T)
{
T* node;
void popFront() {node++;}
... // usual suspects front, empty, etc
}
This seems like cursor!(inout(V)) might work (V is the element type of the
container) as the return type for inout functions. However, one of the
major requirements of inout is that it correctly cast back to the
constancy of the container.
try to return inout(cursor!(Unqual!(V)))
This won't solve the problem. I need inout to be on V, not on the cursor.
return cursor!(Unqual!(inout(V));
?
Re: [std.database] at compile time
On 14.10.2011 19:13, foobar wrote: Andrei Alexandrescu Wrote: On 10/14/11 6:08 AM, Jacob Carlborg wrote: On 2011-10-14 12:19, foobar wrote: Has anyone looked at Nemerle's design for this? They have an SQL macro which allows to write SQL such as: var employName = "FooBar" SQL (DBconn, "select * from employees where name = $employName"); what that supposed to do is bind the variable(s) and it also validates the sql query with the database. This is all done at compile-time. My understanding is that D's compile-time features are powerful enough to implement this. You cannot connect to a database in D at compile time. You could some form of validation and escape the query without connecting to the database. A little SQL interpreter can be written that figures out e.g. the names of the columns involved. Andrei The downsides with writing a separate SQL interpreter are: a) No connection to the DB means no way to validate the schema, e.g. the db might not even have a 'name' column in the employees table. The upside is that you can at least rebuild your app when database is down or compile it on a separate machine. b) No way to validate the SQL per the exact version the DB uses. E.g. LIMIT vs. TOP and also DB vendor specific extensions to SQL syntax. c) NIH - implementing your own SQL interpreter when the DB vendor already provides it. oh, well, perhaps it would be possible with D3 once it supports proper macros. In any case, such a macro probably would be built atop the DB API currently being discussed. -- Dmitry Olshansky
Re: [std.database] at compile time
Andrei Alexandrescu Wrote: > On 10/14/11 6:08 AM, Jacob Carlborg wrote: > > On 2011-10-14 12:19, foobar wrote: > >> Has anyone looked at Nemerle's design for this? > >> They have an SQL macro which allows to write SQL such as: > >> > >> var employName = "FooBar" > >> SQL (DBconn, "select * from employees where name = $employName"); > >> > >> what that supposed to do is bind the variable(s) and it also validates > >> the sql query with the database. This is all done at compile-time. > >> > >> My understanding is that D's compile-time features are powerful enough > >> to implement this. > > > > You cannot connect to a database in D at compile time. You could some > > form of validation and escape the query without connecting to the database. > > A little SQL interpreter can be written that figures out e.g. the names > of the columns involved. > > Andrei The downsides with writing a separate SQL interpreter are: a) No connection to the DB means no way to validate the schema, e.g. the db might not even have a 'name' column in the employees table. b) No way to validate the SQL per the exact version the DB uses. E.g. LIMIT vs. TOP and also DB vendor specific extensions to SQL syntax. c) NIH - implementing your own SQL interpreter when the DB vendor already provides it. oh, well, perhaps it would be possible with D3 once it supports proper macros. In any case, such a macro probably would be built atop the DB API currently being discussed.
Re: [std.database]
OK, for what it's worth, the compiler generated documentation (well, more or less) for my mysqlD effort is now on my web site. The same directory also has the source files and a Code::Blocks project for anyone who uses the latter. I added links to these files at the bottom of the doc. I'll put the stuff on github as soon as I figure out how. The page for now is: http://britseyeview.com/software/mysqld/
Re: eating inout dogfood
On Fri, 14 Oct 2011 09:02:04 -0400, Kagamin wrote: Steven Schveighoffer Wrote: This won't solve the problem. I need inout to be on V, not on the cursor. Essentially, I need cursor to be tail-inout. Since const is transitive, constness of cursor eventually propagates to V. I think you misunderstand the problem. I need constness to be applied to the V, but *NOT* to the cursor. If constness is applied to the cursor, it's not iterable (i.e. popFront does not work). -Steve
Re: [std.database] at compile time
On 10/14/11 6:08 AM, Jacob Carlborg wrote: On 2011-10-14 12:19, foobar wrote: Has anyone looked at Nemerle's design for this? They have an SQL macro which allows to write SQL such as: var employName = "FooBar" SQL (DBconn, "select * from employees where name = $employName"); what that supposed to do is bind the variable(s) and it also validates the sql query with the database. This is all done at compile-time. My understanding is that D's compile-time features are powerful enough to implement this. You cannot connect to a database in D at compile time. You could some form of validation and escape the query without connecting to the database. A little SQL interpreter can be written that figures out e.g. the names of the columns involved. Andrei
Re: eating inout dogfood
Steven Schveighoffer Wrote: > This won't solve the problem. I need inout to be on V, not on the > cursor. Essentially, I need cursor to be tail-inout. Since const is transitive, constness of cursor eventually propagates to V.
Re: eating inout dogfood
On Fri, 14 Oct 2011 04:43:15 -0400, Kagamin wrote:
Steven Schveighoffer Wrote:
struct cursor(T)
{
T* node;
void popFront() {node++;}
... // usual suspects front, empty, etc
}
This seems like cursor!(inout(V)) might work (V is the element type of
the
container) as the return type for inout functions. However, one of the
major requirements of inout is that it correctly cast back to the
constancy of the container.
try to return inout(cursor!(Unqual!(V)))
This won't solve the problem. I need inout to be on V, not on the
cursor. Essentially, I need cursor to be tail-inout.
BTW, this assumes V is not const. I'm not exactly sure how well the
containers work when V is not mutable. I'd expect they would fail
spectacularly :)
-Steve
Re: Statically forbid string ~ size_t ?
On Thu, 13 Oct 2011 18:34:35 -0400, Don wrote:
On 13.10.2011 23:07, bearophile wrote:
This comes from a thread in D.learn.
This is a small Python2 program:
from sys import argv
x = len(argv)
s = "hello"
s += x
print s
Python is strongly typed so it refuses to append an integer number to a
string:
Traceback (most recent call last):
File "...\test.py", line 4, in
s += x
TypeError: cannot concatenate 'str' and 'int' objects
In Java if you append an integer number to a string the integer number
gets first converted to a string:
class Main {
public static void main(String[] args) {
int x = args.length;
String s = "hello";
s += x;
System.out.println(s);
}
}
That Java code outputs:
hello0
Both Java and Python are far more commonly known than D, and they shape
programmers expectations a bit.
This D2 code compiles and runs with DMD 2.056head:
void main(string[] args) {
int x = args.length;
string s = "hello";
s ~= x;
}
(In this case Python2 is typed more strongly than D.)
I think that int+char is acceptable in D, but string~size_t is not
good. I think this is bug prone (especially given the expectations of
programmers coming from other languages). So I suggest to statically
disallow string~size_t. string~char, string~dchar, and string~string
are of course OK.
So far I have written no enhancement request/bug report on this because
I am not so sure...
The problem is things like:
int i;
string s = "0x" ~ ('0' + x);
since char + int --> int.
string s = "0x" ~ cast(char)('0' + x);
Problem solved.
-Steve
Re: [std.database] at compile time
On 2011-10-14 12:19, foobar wrote: Has anyone looked at Nemerle's design for this? They have an SQL macro which allows to write SQL such as: var employName = "FooBar" SQL (DBconn, "select * from employees where name = $employName"); what that supposed to do is bind the variable(s) and it also validates the sql query with the database. This is all done at compile-time. My understanding is that D's compile-time features are powerful enough to implement this. You cannot connect to a database in D at compile time. You could some form of validation and escape the query without connecting to the database. -- /Jacob Carlborg
Re: [std.database] ORM
Am 14.10.2011, 09:27 Uhr, schrieb Steve Teale : 2) would be a thin wrapper around the C API. I think that runs against Phobos' philosophy especially with eventually four layers of abstraction. I'm just saying. Wouldn't mind personally. Marco, Not if it's anything like the piece I'm working on, which if I judge by the effort I've put into it, is not thin. Perhaps I'm at the wrong level. I hope to put an infant version on github before the weekend is out, then you can judge. Steve I wanted to say "don't put a lot of work into D wrappers of C APIs unless you know it has a good chance of getting accepted". I didn't realize you already have something more elaborate and I certainly don't want to judge over what piece of good work gets included. There is just probably one layer too much in the mix to make them all obviously distinctive. There seem to be a lot of database bindings from different people and now is the time that they get a chance to become official standard in Phobos. And with so many different approaches and opinions we might need a few votes at some point. For example I like the layer that hides away the dirty bits (LIMIT vs. TOP, mass INSERTs vs. single row INSERTS, SQL keywords). But since I don't currently use any databases I have no strong opinion.
[std.database] at compile time
Has anyone looked at Nemerle's design for this? They have an SQL macro which allows to write SQL such as: var employName = "FooBar" SQL (DBconn, "select * from employees where name = $employName"); what that supposed to do is bind the variable(s) and it also validates the sql query with the database. This is all done at compile-time. My understanding is that D's compile-time features are powerful enough to implement this.
Re: eating inout dogfood
Steven Schveighoffer Wrote:
> struct cursor(T)
> {
> T* node;
> void popFront() {node++;}
> ... // usual suspects front, empty, etc
> }
>
> This seems like cursor!(inout(V)) might work (V is the element type of the
> container) as the return type for inout functions. However, one of the
> major requirements of inout is that it correctly cast back to the
> constancy of the container.
try to return inout(cursor!(Unqual!(V)))
Re: [std.database] ORM
> > 2) would be a thin wrapper around the C API. I think that runs against > Phobos' philosophy especially with eventually four layers of > abstraction. I'm just saying. Wouldn't mind personally. Marco, Not if it's anything like the piece I'm working on, which if I judge by the effort I've put into it, is not thin. Perhaps I'm at the wrong level. I hope to put an infant version on github before the weekend is out, then you can judge. Steve
Re: [std.database]
Jacob Carlborg wrote: > On 2011-10-12 20:13, Steve Teale wrote: >> The way this discussion is going we're going to have four layers, with >> the top one written by Jacob. > > Hehe. As long as there are database connections available in Phobos and > a fairly good API with different levels available it should be possible > to create an ORM API as a separate project. > That should be the way to go, an ORM is a huge and difficult project.
Re: RIP Dennis Ritchie
On Thu, 13 Oct 2011 15:47:09 -0400, Steven Schveighoffer wrote: > Sad day :( > > -Steve And scary. He was only a year older than me. Steve
