I/O related question, and ini parsing
So, it's my first time implementing something like logging and ini parsing/creating, and it appears to work perfectly, but I'm not neccessarily a master of D yet.. So, I wanted some advice from my seniors if there's anything I should improve on such, I might be missing out on some D-only features, so I'd appreciate it. The important stuff is in /src/breaker/utility: https://github.com/ICGCC/Breaker-3D-Game-Engine I'm a bit curious if my shader loading model is appropriate too, that's in /src/breaker/utility/render.d, but you don't have to worry about that if you're not interested. Anyways, thank you for you time and advice!
Re: I/O related question, and ini parsing
On 12/05/2013 08:43 PM, Mineko wrote:
> I might be missing out on some D-only features
The first thing I've noticed is that you are not using UFCS, perhaps
because you don't like it (yet ;) ) but look how natural the syntax becomes:
existing code (my indentation):
temp = findSplitAfter(findSplitBefore(find(source, var~" = "),
";")[0], " = ")[1];
code taking advantage of D's UFCS (I hope I got it right; I have not
compiled it):
temp = source
.find(var~" = ")
.findSplitBefore(";")[0]
.findSplitAfter(" = ")[1];
Ali
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 05:22:07 UTC, Ali Çehreli wrote:
On 12/05/2013 08:43 PM, Mineko wrote:
> I might be missing out on some D-only features
The first thing I've noticed is that you are not using UFCS,
perhaps because you don't like it (yet ;) ) but look how
natural the syntax becomes:
existing code (my indentation):
temp = findSplitAfter(findSplitBefore(find(source, var~" =
"),
";")[0], " = ")[1];
code taking advantage of D's UFCS (I hope I got it right; I
have not compiled it):
temp = source
.find(var~" = ")
.findSplitBefore(";")[0]
.findSplitAfter(" = ")[1];
Ali
I didn't even know that existed, I'll jump on that right now.
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 05:32:56 UTC, Mineko wrote:
On Friday, 6 December 2013 at 05:22:07 UTC, Ali Çehreli wrote:
On 12/05/2013 08:43 PM, Mineko wrote:
> I might be missing out on some D-only features
The first thing I've noticed is that you are not using UFCS,
perhaps because you don't like it (yet ;) ) but look how
natural the syntax becomes:
existing code (my indentation):
temp = findSplitAfter(findSplitBefore(find(source, var~" =
"),
";")[0], " = ")[1];
code taking advantage of D's UFCS (I hope I got it right; I
have not compiled it):
temp = source
.find(var~" = ")
.findSplitBefore(";")[0]
.findSplitAfter(" = ")[1];
Ali
I didn't even know that existed, I'll jump on that right now.
I went through 8 hours of hell for that.. But it was worth it,
things do look nicer with UFCS stuffs. (No wonder why they say
you don't need a scripting language with D..)
It's on my fork if you wanna check it out:
https://github.com/MinekoRox/Breaker-3D-Game-Engine
Anyways, back to the main subject, anyone know anything that I
could be missing D-only wise as far as file loading, parsing,
creating, etc the stuff in /utility/io.d is doing?
Re: I/O related question, and ini parsing
Mineko: https://github.com/MinekoRox/Breaker-3D-Game-Engine Notes: - Usually in D imports are at the top (after module name and module ddoc). - Perhaps io.getDir is better written an a switch on strings. - I suggest to add the immutable/cost to every variable that doesn't need to mutate, including foreach loop variables. I also suggest to add pure/nothrow annotations where you can, and add pre/post conditions to functions and invariants to structs/classes where convenient (and unittests). Bye, bearophile
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 16:56:29 UTC, bearophile wrote: Mineko: https://github.com/MinekoRox/Breaker-3D-Game-Engine Notes: - Usually in D imports are at the top (after module name and module ddoc). I think it is a bad practice that should be discouraged. Moving as much imports as possible into local scope has lot of practical benefits, primarily maintenance and compilation times. OP still has them global though, just in weird place, that is unusual for sure :)
Re: I/O related question, and ini parsing
Dicebot: I think it is a bad practice that should be discouraged. Moving as much imports as possible into local scope has lot of practical benefits, primarily maintenance and compilation times. Right. I was referring to the global ones. Bye, bearophile
Re: I/O related question, and ini parsing
Alright cool, I'll get on that real soon, I'm not too used to D's importing system anyway, so I appreciate it. I suppose I'll have to do some research on pure and nothrow too, I've never really bothered with those.
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 04:43:44 UTC, Mineko wrote: So, it's my first time implementing something like logging and ini parsing/creating, and it appears to work perfectly, but I'm not neccessarily a master of D yet.. So, I wanted some advice from my seniors if there's anything I should improve on such, I might be missing out on some D-only features, so I'd appreciate it. The important stuff is in /src/breaker/utility: https://github.com/ICGCC/Breaker-3D-Game-Engine I'm a bit curious if my shader loading model is appropriate too, that's in /src/breaker/utility/render.d, but you don't have to worry about that if you're not interested. Anyways, thank you for you time and advice! imports are private by default. Also I noticed few overlaping private declarations, for example here: https://github.com/MinekoRox/Breaker-3D-Game-Engine/blob/master/src/breaker/utility/belt.d#L54
Re: I/O related question, and ini parsing
On Saturday, 7 December 2013 at 12:23:38 UTC, nazriel wrote: On Friday, 6 December 2013 at 04:43:44 UTC, Mineko wrote: So, it's my first time implementing something like logging and ini parsing/creating, and it appears to work perfectly, but I'm not neccessarily a master of D yet.. So, I wanted some advice from my seniors if there's anything I should improve on such, I might be missing out on some D-only features, so I'd appreciate it. The important stuff is in /src/breaker/utility: https://github.com/ICGCC/Breaker-3D-Game-Engine I'm a bit curious if my shader loading model is appropriate too, that's in /src/breaker/utility/render.d, but you don't have to worry about that if you're not interested. Anyways, thank you for you time and advice! imports are private by default. Also I noticed few overlaping private declarations, for example here: https://github.com/MinekoRox/Breaker-3D-Game-Engine/blob/master/src/breaker/utility/belt.d#L54 Ahh thank you for pointing that overlap. I know imports are private, only reason I put them at the bottom is because the public stuff is what you're referencing to when you import something, not the private stuff (usually) Although I've been thinking of at least moving the imports back to the top, since it does make more sense that way.
Re: I/O related question, and ini parsing
On Saturday, 7 December 2013 at 12:23:38 UTC, nazriel wrote: imports are private by default. Also I noticed few overlaping private declarations, for example here: https://github.com/MinekoRox/Breaker-3D-Game-Engine/blob/master/src/breaker/utility/belt.d#L54 Sorry for the double post, this just occured to me, and it'll keep me from getting lectured about scopes and imports. :P On Friday, 6 December 2013 at 17:32:24 UTC, Dicebot wrote: On Friday, 6 December 2013 at 16:56:29 UTC, bearophile wrote: Mineko: https://github.com/MinekoRox/Breaker-3D-Game-Engine Notes: - Usually in D imports are at the top (after module name and module ddoc). I think it is a bad practice that should be discouraged. Moving as much imports as possible into local scope has lot of practical benefits, primarily maintenance and compilation times. OP still has them global though, just in weird place, that is unusual for sure :) I'll probably just do that, actually, as I like having benefits.
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 05:32:56 UTC, Mineko wrote:
On Friday, 6 December 2013 at 05:22:07 UTC, Ali Çehreli wrote:
On 12/05/2013 08:43 PM, Mineko wrote:
> I might be missing out on some D-only features
The first thing I've noticed is that you are not using UFCS,
perhaps because you don't like it (yet ;) ) but look how
natural the syntax becomes:
existing code (my indentation):
temp = findSplitAfter(findSplitBefore(find(source, var~" =
"),
";")[0], " = ")[1];
code taking advantage of D's UFCS (I hope I got it right; I
have not compiled it):
temp = source
.find(var~" = ")
.findSplitBefore(";")[0]
.findSplitAfter(" = ")[1];
Ali
I didn't even know that existed, I'll jump on that right now.
You can read more about that here:
http://nomad.so/2013/08/alternative-function-syntax-in-d/
