opIndexAssign for shader parameters

[patrickjm]

I'm not entirely sure if this is a good idea or not - it seems convenient, but I'm more concerned that it goes against the design model you have for DSFML (that is, more focus on staying true-to-form). Regardless, I thought I'd bring it up.

With these index assign overloads in shader, something like this could happen (reminiscent of how XNA decided to do things):

myShader["bumpMap"] = someTexture;
myShader["values"] = [15, 24.6, 200];
myShader["backColor"] = Color.Red;

Note that these are only assign overloads. You can't read values this way, only write, which seems appropriate.

[Jebbs]

This is really awesome! I've been thinking it would be neat to have something similar to this, but never got around to it. Give me some time to finish up the last few unit tests(I think it is just the networking module at this point) so I can find any remaining bugs here and there. After that, I'm going to call 2.0 finished and get to work on 2.1. Then I will merge this.

And just so you know, as time goes on I think it makes sense for DSFML to evolve in such a way that makes it better as a D library, not just being the D counterpart to the C++ code. Sure, there are a lot of things I would like to keep to make it easy to port a C++ project over to D quickly, but new features that make it a better library(like the one you just suggested) are what is going to really make this project shine. I have a lot of good ideas for the future. ;)

[patrickjm]

That's great! It'll take more work, but it should turn out as a much better library to keep things in line with what D can offer. Hopefully #85 works out well.

[Jebbs]

There have been many changes since you opened this pull request. Would you mind updating your fork and then resubmitting your changes?

[Jebbs]

Hmm.. I might actually be able to make it work. I'll try something tomorrow.

[Jebbs]

I waited so long that there are quite a few things to update, but I'll have this merged soon.

[Jebbs]

Just a quick thought.

Your index overload for dealing with possible multiple numbers of float parameters is interesting, but I think I might change it a little. Here are two possibilities:

1. Leave as is, except do a compile time and run time check for an array of length >4 or <1.
2. Split it into different functions and make them be static arrays for each length instead of a dynamic one.

Thoughts?

[Jebbs]

Personally, I like 2 better, but I am also considering using a set of tuple overloads (from std.typecons) which I think I like even more, but until I get your input I'll just stick with 1.