On 8/4/21 4:18 AM, evilrat wrote:
On Wednesday, 4 August 2021 at 07:21:56 UTC, Denis Feklushkin wrote:
On Sunday, 1 August 2021 at 17:37:01 UTC, evilrat wrote:
vibe-d - probably because it handles DB connection and/or keep things
async way, sure you probably can do it with Phobos but it will
On Wednesday, 4 August 2021 at 08:18:34 UTC, evilrat wrote:
Than again like I said it is library author mistake, if only
JSON is ever used then it should depend on vibe-d:data
specifically and not the whole vibe-d thing.
It is also a problem with dub though since D, the language,
supports
On Tuesday, 3 August 2021 at 00:54:56 UTC, Steven Schveighoffer
wrote:
Given the way D works, and often template-heavy coding styles,
I think it's going to be hard to do this correctly, without
careful attention and lots of `version(has_xxx)` conditionals.
-Steve
I don't think optional
On Wednesday, 4 August 2021 at 07:21:56 UTC, Denis Feklushkin
wrote:
On Sunday, 1 August 2021 at 17:37:01 UTC, evilrat wrote:
vibe-d - probably because it handles DB connection and/or keep
things async way, sure you probably can do it with Phobos but
it will be much more PITA and less
On Sunday, 1 August 2021 at 17:18:39 UTC, Alain De Vos wrote:
A simple and small wrapper around for instance the C-library
Really, dpq2 is that wrapper
On Sunday, 1 August 2021 at 17:37:01 UTC, evilrat wrote:
vibe-d - probably because it handles DB connection and/or keep
things async way, sure you probably can do it with Phobos but
it will be much more PITA and less performant
It is because Postgres provides JSON types
On 8/1/21 11:38 AM, Alain De Vos wrote:
Dub has two big problems.
1. Unmaintained dub stuff.
2. Let's say you need bindings to postgresql library and you will see
dub pulling in numerous of libraries, which have nothing at all to do
with postgresql.
More like a framework stuff. This creates
On 02/08/2021 5:18 AM, Alain De Vos wrote:
A simple and small wrapper around for instance the C-library libpq
should be part of the language itself and should not pull in more than
libpq itself.
Just so that we are all using the same terminology.
A binding defines the functions and types
On Sunday, 1 August 2021 at 17:25:26 UTC, Alain De Vos wrote:
A simple example, dub package dpq2 pulls in,
money,vide-d,stdx-allocator,derelict-pq,derelict-util
This all for a handfull of C-functions.
let's see
Money - fits pretty ok, cause your average SQL has decimal type
for that purpose
On Sunday, 1 August 2021 at 17:18:39 UTC, Alain De Vos wrote:
A simple and small wrapper around for instance the C-library
libpq should be part of the language itself and should not pull
in more than libpq itself.
I don't disagree. The question is, who will volunteer to create
and maintain
A simple example, dub package dpq2 pulls in,
money,vide-d,stdx-allocator,derelict-pq,derelict-util
This all for a handfull of C-functions.
On Sunday, 1 August 2021 at 17:18:39 UTC, Alain De Vos wrote:
A simple and small wrapper around for instance the C-library
libpq should be part of the language itself and should not pull
in more than libpq itself.
i have one of those in two files: database.d for the interface
and postgres.d
A simple and small wrapper around for instance the C-library
libpq should be part of the language itself and should not pull
in more than libpq itself.
On Sunday, 1 August 2021 at 15:38:32 UTC, Alain De Vos wrote:
Dub has two big problems.
1. Unmaintained dub stuff.
2. Let's say you need bindings to postgresql library and you
will see dub pulling in numerous of libraries, which have
nothing at all to do with postgresql.
More like a framework
On Sunday, 1 August 2021 at 15:38:32 UTC, Alain De Vos wrote:
2. Let's say you need bindings to postgresql library and you
will see dub pulling in numerous of libraries, which have
nothing at all to do with postgresql.
More like a framework stuff. This creates unneeded complexity,
bloatware,
Is there a security review for dub packages ?
Dub has two big problems.
1. Unmaintained dub stuff.
2. Let's say you need bindings to postgresql library and you will
see dub pulling in numerous of libraries, which have nothing at
all to do with postgresql.
More like a framework stuff. This creates unneeded complexity,
bloatware, dependency
17 matches
Mail list logo
