Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 6 February 2023 at 21:02:13 UTC, Richard (Rikki) Andrew Cattermole wrote: On 07/02/2023 9:56 AM, ProtectAndHide wrote: On Monday, 6 February 2023 at 08:26:45 UTC, Ali Çehreli wrote: In contrast, D delivers some features in an unprincipled way and the programmers use combinations of those features the way the see fit. I agree, that D is unprincipled in many ways, and this is perhaps the biggest surprise for new comers from other 'principled' programming languages. But is that a design goal for D? Yes. Not all problems are best solved the same way as another. Use what is best for you & your problem domain, not what somebody is selling as the next big thing. Well I don't agree that D should boast about things that's its implemented in an unprincipled way. I find that a strange form of marketing in todays world. To the extent those unprincipled implementations allow you to do things that you do actually want to do, then fine.. maybe. But an unprincipled implementation of something that just allows you do make mistakes, then it should be looked at further, so see if it can be improved.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 6 February 2023 at 21:46:29 UTC, Ali Çehreli wrote: On 2/6/23 12:56, ProtectAndHide wrote: > I'm not going to 'go write a > DIP'. Nobody will write a DIP about it because very few people ever mentioned this issue over the years. And as 'static class' and 'static struct' are already usable in D, a newcomer would definitely be confused with your "terrible" conclusion. Ali You being a little agressive don't you think? My observation is very reasonable, and correct, and a new comer to D would do well to know that: The compiler will allow you to do all these things, even if you've @disable'd' the constructor, and have only static members: - the compiler will allow you to declare a variable of that type - the compiler will allow you to declare an array with elements of that type - the compiler will allow you to use that type as a type argument - the compiler will allow you to use that type as a parameter - the compiler will allow you to use that type as a return type I can see no reason why anyone would want to do these things, in this context. Nor can I see any reason, whatsoever, why the compiler would allow you to do these things, in this context. It's not about me trying to remove power from the programmer. That's a nonsense argument, without any basis, whatsoever. It's just a (correct) observation. Further comments that try to derail this will be ignored.
Re: ImportC "no include path set"
On Monday, 6 February 2023 at 14:35:53 UTC, bachmeier wrote: On Monday, 6 February 2023 at 06:55:02 UTC, Elfstone wrote: So how am I supposed to set the include path? https://dlang.org/spec/importc.html#preprocessor The -Ppreprocessorflag switch passes preprocessorflag to the preprocessor. So if you normally use `-I/foo`, you'd add `-P-I/foo`. Thanks, it worked, but I still get the link error. I wasn't expecting to configure include paths and link the right libc myself. The doc says the simple "dmd hello.c" should create "hello.exe". It must be a bug.
Re: Non-ugly ways to implement a 'static' class or namespace?
On 2/6/23 12:56, ProtectAndHide wrote: > I'm not going to 'go write a > DIP'. Nobody will write a DIP about it because very few people ever mentioned this issue over the years. And as 'static class' and 'static struct' are already usable in D, a newcomer would definitely be confused with your "terrible" conclusion. Ali
Re: Non-ugly ways to implement a 'static' class or namespace?
On 07/02/2023 9:56 AM, ProtectAndHide wrote: On Monday, 6 February 2023 at 08:26:45 UTC, Ali Çehreli wrote: In contrast, D delivers some features in an unprincipled way and the programmers use combinations of those features the way the see fit. I agree, that D is unprincipled in many ways, and this is perhaps the biggest surprise for new comers from other 'principled' programming languages. But is that a design goal for D? Yes. Not all problems are best solved the same way as another. Use what is best for you & your problem domain, not what somebody is selling as the next big thing.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 6 February 2023 at 08:26:45 UTC, Ali Çehreli wrote: In contrast, D delivers some features in an unprincipled way and the programmers use combinations of those features the way the see fit. I agree, that D is unprincipled in many ways, and this is perhaps the biggest surprise for new comers from other 'principled' programming languages. But is that a design goal for D? I really don't care if D had 'static class' to be used only as a namespace but I don't see how this issue is terrible If you've ever programmed in C#, you've use static classes, and you've used them many times, and you'll continue to use them. If D implemented the same abstraction as easily as C#, then C# programmers would find it easier to migrate code to D, perhaps. That's not a request, just an observation. And no, I'm not going to 'go write a DIP'. Of course, if I was talking about migrating C code, you'd all be stumbling over yourselves to make that happen - .. build it, and they still won't come ;-)
Re: betterC DLL in Windows
On Monday, 6 February 2023 at 15:54:40 UTC, bachmeier wrote: This is the specification for the D Programming Language. I've been bitten by that a few times over the years, though to be honest, I'm not sure of the relationship of the spec to documentation. The Phobos documentation and compiler documentation appear to be actual documentation, in the sense that you can trust it to be accurate, and if not it's a bug. I see... I guess I was confused by the title of the link, "Language Reference" on the Docs page, and didn't look carefully at the URL or the text after that.
Re: betterC DLL in Windows
On Sunday, 5 February 2023 at 19:00:16 UTC, Richard (Rikki) Andrew Cattermole wrote: So LDC with druntime and yes GC turned on is good enough right now that you can probably make it work without too much effort. You don't necessarily have to limit yourself to -betterC. In fact if you don't, you have access to PyD[0] which can handle the interop stuff for you. I haven't personally used it, but it might work for your use case :) [...] But yeah if you can avoid having to create bindings for stuff (such as glib which we have bindings for), or wrappers ext. do so. That way you can do more of the fun things! Sounds quite convincing, I think I might do it this way, instead of with betterC. Not needing additional python bindings does sound like a big plus. Thanks.
Re: staticMap but with two arguments
On Monday, 6 February 2023 at 09:17:07 UTC, Ali Çehreli wrote: I adapted staticMap's implementation to two sets of arguments: Thanks Ali, that's perfect. I thought of splitting the args in half a few hours later but hadn't got around to trying it.
Re: betterC DLL in Windows
On Mon, Feb 06, 2023 at 03:54:40PM +, bachmeier via Digitalmars-d-learn wrote: > On Sunday, 5 February 2023 at 08:48:34 UTC, Tamas wrote: [...] > > This is the specification for the D Programming Language. > > I've been bitten by that a few times over the years, though to be > honest, I'm not sure of the relationship of the spec to documentation. > The Phobos documentation and compiler documentation appear to be > actual documentation, in the sense that you can trust it to be > accurate, and if not it's a bug. Maybe someone that has been around > from the earliest days understands the goal of the spec. IIRC the spec was started as part of an ongoing effort to fully specify the language so that, at least in theory, someone could read the spec and implement a D compiler completely independent of the current ones. T -- INTEL = Only half of "intelligence".
Re: betterC DLL in Windows
On Sunday, 5 February 2023 at 08:48:34 UTC, Tamas wrote: I appreciate all of this... however, as a newcomer, I wish the docs were simply more honest, instead of representing wishful thinking. I guess in any programming language, experience reveals things not present in the docs, but it seems to apply much more acutely here. Technically, those pages are [the spec rather than documentation](https://dlang.org/spec/spec.html). This is the specification for the D Programming Language. I've been bitten by that a few times over the years, though to be honest, I'm not sure of the relationship of the spec to documentation. The Phobos documentation and compiler documentation appear to be actual documentation, in the sense that you can trust it to be accurate, and if not it's a bug. Maybe someone that has been around from the earliest days understands the goal of the spec.
Re: ImportC "no include path set"
On Monday, 6 February 2023 at 06:55:02 UTC, Elfstone wrote: So how am I supposed to set the include path? https://dlang.org/spec/importc.html#preprocessor The -Ppreprocessorflag switch passes preprocessorflag to the preprocessor. So if you normally use `-I/foo`, you'd add `-P-I/foo`.
Re: SFML D bindings: libsfml-system.so.2.5: cannot open shared object file:
On Sunday, 5 February 2023 at 03:38:04 UTC, thebluepandabear wrote: On Sunday, 5 February 2023 at 03:19:43 UTC, bachmeier wrote: Something of a puzzle that it works with Arch, though, but not Ubuntu/Mint. It doesn't sound like Arch has that problem. What problem doesn't Arch have, the missing symbol or the shared library one? The earlier post in this thread implied there were no problems on Arch. I'm wondering, after downgrading, do you get the shared library issue that I am currently dealing with? I'm not sure how to downgrade. I installed the package from the repos. I can't say a bug in the Ubuntu packaging would surprise me.
Re: A potential use-case for template mixins?
On Monday, 6 February 2023 at 12:22:19 UTC, Matt wrote: I am (still) writing a 3D graphics engine, and was considering my choices for a scene graph. Originally, I was going to use classes derived from my base SceneNode class for the nodes of the graph, but would this instead be a better situation to use template mixins instead of potentially having to include a lot of information in the base class? Or should I go with the traditional "everything is derived from the base class"? I understand if this is light on details, I'll try and provide more if necessary, but I'm really not far into the design beyond this, and was wondering which would make for an easier path in the future Use classes. Mixin template are only relevant to types which understands the mixin template or when you want to create a similar object with similar behavior, but they mustn't be the same thing. That means, you need to ducktype everything in order to work which could bring a template hell in your code. Unless you try to do generics in your code or make it componetized rather than inherited, but that could affect your coding style by manually passing the node that your object has, this can be quite the manual work though.
A potential use-case for template mixins?
I am (still) writing a 3D graphics engine, and was considering my choices for a scene graph. Originally, I was going to use classes derived from my base SceneNode class for the nodes of the graph, but would this instead be a better situation to use template mixins instead of potentially having to include a lot of information in the base class? Or should I go with the traditional "everything is derived from the base class"? I understand if this is light on details, I'll try and provide more if necessary, but I'm really not far into the design beyond this, and was wondering which would make for an easier path in the future
Re: staticMap but with two arguments
On 2/5/23 17:20, John Chapman wrote:
> staticMap's "fun" can only be
> instantiated with a single argument, while I need it to work with two.
I adapted staticMap's implementation to two sets of arguments:
import std.meta : AliasSeq;
// The first half of 'args' is the "first arguments" and
// the second half is the "second arguments".
//
// (This can be generalized to N sets of arguments.)
template staticMap2(alias fun, args...)
{
alias firsts = args[0 .. $ / 2];
alias seconds = args[$ / 2 .. $];
static assert(firsts.length == seconds.length,
"Mismatched number of first and second arguments");
alias staticMap2 = AliasSeq!();
static foreach (i; 0 .. firsts.length) {
staticMap2 = AliasSeq!(staticMap2, fun!(firsts[i], seconds[i]));
}
}
// An example struct with two template parameters
struct S(T, size_t length) {
}
// An example template that creates instantiations of the S template
// (This can be generalized to instantiation of any template.)
template Instantiate(T, size_t length) {
alias Instantiate = S!(T, length);
}
// An example use
alias myTypes = AliasSeq!(int, double, long);
alias mySizes = AliasSeq!(1, 2, 3);
alias result = staticMap2!(Instantiate, myTypes, mySizes);
pragma(msg, result);
void main() {
}
Ali
Re: compile: link dynamic OR static library in Windows
On Monday, 6 February 2023 at 08:23:37 UTC, Richard (Rikki) Andrew Cattermole wrote: [...] Yes, your solution works. I apologize for my inattention. I should have checked earlier in your way. Most likely Adam has a [problem](https://github.com/adamdruppe/arsd/issues/364) with linking in the library.
Re: ImportC "no include path set"
On 2/5/23 22:55, Elfstone wrote: > So how am I supposed to set the include path? I am not familiar with D in Windows but my first guess would be the -I compiler switch: dmd -I=/my/c/headers ... Ali
Re: Non-ugly ways to implement a 'static' class or namespace?
On 2/5/23 18:15, ProtectAndHide wrote:
> I do not agree, that a compiler that allows a programmer to misuse a
> type
Types normally have objects. If a programmer found a way to use objects
of a memberless type why stop them?
> should be seen as 'a feature'.
I am not saying I already see those uses as features. I am questioning
why the compiler should ban certain features. Rather, why would a
programmer decide that another programmer should not have objects of a
certain type?
What is the actual insurmountable problem here? C#'s having 'static
class' cannot be an answer because I can't imagine somebody even in C#
wanted to have such a thing. For all I know, they wanted something else
(namespacing in this case) and implemented it as 'static class'.
On the other hand, it is possible that C# brings different semantics
that I don't know yet. What is that semantics? How does D already solve
that?
> If that's the kind of 'power' D programmers want,
The trait here is orthogonality: Let's say A, B, C, etc. are features of
a language. Some combination of those features work together for various
reasons.
On the other hand, some combinations may not work well and people don't
or can't use them for various reasons:
- The language may ban them because there may be dangerous ambiguities
with that combination
- There may be technical impossibilities for that combination
- That combination can have no agreeable semantics (your earlier
examples are in this category)
- People would never think about that combination (to me, at least some
of your examples are in this category)
- People may decide not to use that combination in coding guidelines
- etc.
So, what I am understanding is that thebluepandabear and you are asking
the compiler to ban certain combinations. For example, using a struct
for namespacing (A) and being able to create objects (B) used together
should not be allowed.
What other combinations can we come up with for such a list? As you
said, certain uses of the 'static' keyword at module scope has no effect
in D ('statis this' and 'shared static this' should be considered
multi-word keywords and I think 'static const' has a meaning). Should
the D spec enumerate all ineffective uses of 'static' (and others) and
ban them? I don't agree.
In contrast, D delivers some features in an unprincipled way and the
programmers use combinations of those features the way the see fit.
I really don't care if D had 'static class' to be used only as a
namespace but I don't see how this issue is terrible. If the programmers
ever need to use a struct (or a class) for namespacing then they
wouldn't need objects of such types either. So, they wouldn't do that.
Ali
Re: Non-ugly ways to implement a 'static' class or namespace?
On 2/5/23 17:50, thebluepandabear wrote: > I don't see why you'd want I am not saying it would be wanted or needed. > to expose a static class/namespace as a > variable, or any of such similar things. That would give no benefits to > the programmer? Perhaps. As I responded to ProtectAndHide, if there is a benefit then it is useful by definition; if there is no benefit then it wouldn't be used anyway. Ali
Re: compile: link dynamic OR static library in Windows
On 06/02/2023 8:43 PM, Alexander Zhirov wrote:
Is it possible to collect all this from under mingw so that the linker
is not Microsoft, but `ld'?
Maybe. Keep in mind that mingw isn't the system toolchain, you'll
probably run into issues using it else where. You should really be using
MSVC.
We support the system toolchain solely pretty much.
So I just downloaded libpq from the site (64bit version for Windows,
15.1). https://www.enterprisedb.com/download-postgresql-binaries
Copied lib+bin directory into working directory from the zip file.
```sh
alpha@DESKTOP-RB97SA4 /tmp/test_libpq
$ tree -L 1
.
├── bin
├── lib
├── test.d
├── test.exe
└── test.obj
2 directories, 3 files
```
Source file:
```d
module test;
import std.stdio;
void main() {
writeln("start");
PGconn* conn = PQconnectdb("connection string");
assert(conn !is null);
PQfinish(conn);
writeln("end");
}
struct PGconn;
extern(C) {
PGconn* PQconnectdb(const char *conninfo);
void PQfinish(PGconn* conn);
}
```
Output:
```sh
alpha@DESKTOP-RB97SA4 /tmp/test_libpq
$ dmd -m64 lib/libpq.lib test.d
alpha@DESKTOP-RB97SA4 /tmp/test_libpq
$ PATH=$PATH:lib:bin ./test
start
end
```
I had to modify the PATH variable to setup the lib and bin directories
for DLL lookup (bash syntax for Cygwin).
Appears to work fine.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Sunday, 5 February 2023 at 23:53:35 UTC, Ali Çehreli wrote: I understand disabling the programmer to do certain things are beneficial e.g. to prevent bugs but those above can all be seen as features. What is so terrible about giving the programmer those powers? Ali Interestingly, in Swift, you cannot (as far as I can tell) disable init() like you can in D. Thus you cannot prevent the programmer from creating an instance of a class. And you can forget about 'C# like' static classes in Swift also. That leaves the question of why 'any' programming language would allow you to instantiate a class that has only static members. What exactly are you going to do with that instance? (i.e. there are no 'instance' members, just 'type' members). At least in D you CAN disable the initialiser with @disable. But even after you've done that, the compiler still: - allows you to declare a variable of that type - allows you to declare an array with elements of that type - allows you to use that type as a type argument - allows you to use that type as a parameter - allows you to use that type as a return type So, getting back to your statement.. under what circumstance would a programmer want the 'power' to do any or all of this things, if the programmer has explicately disabled the initialiser, and the type has only static 'type' members?
