As some might know I'm currently converting my 3D engine's source code from C++ to D. But now I'm stuck with something of which I can't believe that it might not be possible with D:

As one might expect the engine also manages textures, and OpenGL textures have so called parameters. Now counting 2 and 2 I thought: "OpenGL Texture parameters, hmm D supports parameter assignment syntax, too, that makes things look much nicer":

class GLTexture : Texture
{
        GLint min_filter(GLint _filter) {
                glTexParameteri(Target, GL_TEXTURE_MIN_FILTER, _filter);
                return _filter;
        }
        GLint min_filter() {
                GLint _filter;
                glGetTexParameteri(Target, GL_TEXTURE_MIN_FILTER, &_filter);
                return _filter;
        }

        GLint mag_filter(GLint _filter) {
                glTexParameteri(Target, GL_TEXTURE_MAG_FILTER, _filter);
                return _filter;
        }
        GLint mag_filter() {
                GLint _filter;
                glGetTexParameteri(Target, GL_TEXTURE_MAG_FILTER, &_filter);
                return _filter;
        }
/*
...
*/

private:
        const GLenum Target;
}

However this looks rather crude and shouts for generic programming. Instead just writing

        mixin GLTemplateParameter!(GL_TEXTURE_MIN_FILTER, min_filter);

or something similair would be much nicer, shorter and less error prone. But there's the problem, that I don't know (or that there might not be the possibility) to give a name as parameter, that will be used for declaration naming.

Probably I'm just too stupid, but if that's really a missing feature, then I plead to add it.

Wolfgang Draxinger

Wolfgang Draxinger wrote:

>         mixin GLTemplateParameter!(GL_TEXTURE_MIN_FILTER,
>         min_filter);

Err, should be of course GLTextureParameter.

Wolfgang Draxinger
-- 

how about something like this ?


template Mixer(T, int paramType) {
	void foo(T value) {
		static if (is(T == int)) {
			// glTexParameteri...
		}
		else static if (is(T == float)) {
			// glTexParameterf
		}
	}
	
	T foo() {
		// ...
		return 11111;
	}
}

const int GL_TEXTURE_MIN_FILTER = 666;

class Foo {
	mixin Mixer!(int, GL_TEXTURE_MIN_FILTER) min_filter_;
	alias min_filter_.foo min_filter;
}


void main () {
	auto f = new Foo;
	f.min_filter = 1;
	int a = f.min_filter;
}



btw, does your engine have some place in the net ? i'd be curious to see it :)



Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

X-Post to digitalmars.D due to language enhancement suggestion.

Tom S wrote:

> class Foo {
> mixin Mixer!(int, GL_TEXTURE_MIN_FILTER) min_filter_;
> alias min_filter_.foo min_filter;
> }

That's line to much. Otherwise I could also write

template GLTextureParameterI_Set(GLenum Param)(T value) {
glTexParameteri(Target, Param, value);
return value;
}

template GLTextureParameterI_Get(GLenum Param)() {
GLint value;
glGetTexParameteri(Target, Param, &value);
return value;
}

class Foo
{
        mixin GLTextureParameterI_Set(GL_TEXTURE_MIN_FILTER) min_filter;
        mixin GLTextureParameterI_Get(GL_TEXTURE_MIN_FILTER) min_filter;
};

My idea would have been, to extend the declaration of Templated with something resembling marco unfolding without introducing it's problems.

I'd like to write e.g the following (note the '#' indicating, that the template parameter "name" is to be literally replaced by what is written at the respective point in the template instanciation. The rule would be, that what follows after a '#' in a template must be a valid identifier and not a statement or expression. The usage of such a parameter within a template declaration would automatically limit it's usage to mixins; implicit mixin expansion could be assumed, but I'd discourage that):

template GLTexParameter(T type, GLenum Param, #name)
{
        T #name(T value)
        {
                static if ( is ( T == GLint ) ) {
                        glTexParameteri(Target, Param, value);
                } else static if ( is ( T == GLfloat ) ) {
                        glTexParameterf(Target, Param, value);
                }
                return value;
        }

        T #name()
        {
                T value;
                static if ( is ( T == GLint ) ) {
                        glGetTexParameteriv(Target, Param, &value);
                } else static if ( is ( T == GLfloat ) ) {
                        glGetTexParameterfv(Target, Param, &value);
                }
                return value;
        }
}

class Texture
{
        mixin GLTexParameter!(GLint, GL_TEXTURE_MIN_FILTER, min_filter);
        mixin GLTexParameter!(GLint, GL_TEXTURE_MAG_FILTER, mag_filter);
        mixin GLTexParameter!(GLfloat, GL_TEXTURE_PRIORITY, priority);
/*...*/
}

I used a '#' since it is not being assumed a token by the D specs right now. I'd also like '$' like in shell scripts or Perl, but that's a D token already, but right now I can't remember what it is for, or if it's actually used.

> btw, does your engine have some place in the net ? i'd be curious to see it :)

There's nothing to be seen outstanding right now (except some simple screenshots of single objects), because it's not done yet. I switched to D, since I got sick with C++ during development. Ever tried to make self reflecting components in C++, _with_ template support?

D is a great language for this OTOH for a few reasons: It's easy to parse. There exists a good frontend for GCC and it delivers all data that is needed for self reflection.

About one year ago I was looking around for nicer methods on implementing it, which was, when I came to D.

Rest assured, that as soon the engine is done I'm going to announce it's release on the D newsgroups.

Check http://www.darkstargames.de/ and if you don't want to loose your eyes for eye cancer better do it in about 2 months and then go directly to http://www.darkstargames.de/even ;-) In about a week the semester break begins and I got 3 months worth of time to spend only my private projects, which one of them is to make a new XHTML compliant homepage with sane CSS and modern look.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867

On Mon, 24 Jul 2006 22:14:30 +0200, Wolfgang Draxinger wrote:


> Probably I'm just too stupid, but if that's really a missing feature, then I plead to add it.

I have trouble understanding mixins too. They seem to solve half the problem I have and create two more while doing so. I suspect that I'm trying to do more than Walter believes should be allowed. The syntax and usage is more obtuse and misleading than C++ templates IMHO.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Wolfgang Draxinger wrote:

> I used a '#' since it is not being assumed a token by the D specs right now.

In fact it's used for special token sequences: http://www.digitalmars.com/d/lex.html#specialtokenseq (although I don't see much use in #line)

See also discussion here: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39264

Looks like we have only '@' symbol to use.

What you are talking about is actually more powerful metaprogramming. I'm afraid it's postponed to D 2.0.

-- 
AKhropov

Andrei Khropov wrote:
> Wolfgang Draxinger wrote:
> 
> 
>>I used a '#' since it is not being assumed a token by the D specs
>>right now.
> 
> 
> In fact it's used for special token sequences:
> http://www.digitalmars.com/d/lex.html#specialtokenseq (although I don't see much use in #line)
> 

I see use for #line.
I'm not sure how practical it would be to write, but at some point I'd like to write or have a tool that can rewrite D source code, a preprocessor of sorts but not really.

It would do stuff like:
- Eliminate dead code.
- Insert things like "assert( object !is null )" just before "object.member".
- Automatically add "delete object;" where it can be proven at compile-time that object can safely be deleted.
- Source level linking - Merge a build of sourcefiles together into one sourcefile, possibly allowing the compiler to do better global optimizations. (I just had a case where changing a public method to a private method created about a 100x speedup in execution of that method, possible inlining?)
- probably more cool stuff etc...

For at least the first thing, and maybe the first few, it would be helpful to be able to change the line number so that the line numbers map back to the original source files while debugging.

<rambling>
In a way I wonder if such a tool could eventually take over some of the functionality provided by a D compiler; stuff that doesn't necessarily map directly to machine code, like array bounds checking, enums, constants, constant expression evalution, etc.  It would be slower compilation, but it could allow new D compilers to become functional more quickly.
</rambling>

> See also discussion here:
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39264
> 
> Looks like we have only '@' symbol to use.
> 
> What you are talking about is actually more powerful metaprogramming.
> I'm afraid it's postponed to D 2.0.
> 

Derek wrote:
> On Mon, 24 Jul 2006 22:14:30 +0200, Wolfgang Draxinger wrote:
> 
> 
>> Probably I'm just too stupid, but if that's really a missing
>> feature, then I plead to add it.
> 
> I have trouble understanding mixins too. They seem to solve half the
> problem I have and create two more while doing so. I suspect that I'm
> trying to do more than Walter believes should be allowed. The syntax and
> usage is more obtuse and misleading than C++ templates IMHO.

They work brilliantly for creating nested functions, but so far I haven't found them to be useful for anything else. I think they'll need to be totally revamped eventually; there's some serious problems with them in their current form. I'd advise against using them if there's a reasonable alternative.

Don Clugston wrote:
> Derek wrote:
> 
>> On Mon, 24 Jul 2006 22:14:30 +0200, Wolfgang Draxinger wrote:
>>
>>
>>> Probably I'm just too stupid, but if that's really a missing
>>> feature, then I plead to add it.
>>
>>
>> I have trouble understanding mixins too. They seem to solve half the
>> problem I have and create two more while doing so. I suspect that I'm
>> trying to do more than Walter believes should be allowed. The syntax and
>> usage is more obtuse and misleading than C++ templates IMHO.
> 
> 
> They work brilliantly for creating nested functions, but so far I haven't found them to be useful for anything else. I think they'll need to be totally revamped eventually; there's some serious problems with them in their current form. I'd advise against using them if there's a reasonable alternative.

David Rushby's update of the Python header uses them in place of some macros in the original C version. Most of the raw Python/C API revolves around a series of structs, all of which share a certain series of fields in common. So at the root of all these structs is this template:

template PyObject_HEAD() {
    int ob_refcnt;         // The reference count of the object
    PyTypeObject *ob_type; // A pointer to the object's type object
}

Most operations in the API involve passing PyObject*s around; the PyObject struct is simply defined like this:

struct PyObject {
    mixin PyObject_HEAD;
}

And then, any other types defined in the API just add their own fields after the mixin:

struct PySomeType {
    mixin PyObject_HEAD;
    int some_field;
}

In this way is inheritance simulated in a C API. Where PyObject_HEAD is a macro in C, it is a much safer mixin in D.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Andrei Khropov wrote:

> Looks like we have only '@' symbol to use.

Looks nice, too.

> What you are talking about is actually more powerful metaprogramming. I'm afraid it's postponed to D 2.0.

Sad, that would have made my engine's source code, especially in the renderer part a lot of shorter and readable.

But may I make a suggestion for D 1.0 here, that would at least allow usage as I have in mind, i.e. using template mixins as a stock function generator, by adding following rule to templates:

If a template only contains functions of the name of the template, and the function declarations adhere the overloading rules the template is a multifunction template.

Example:

template Foo (T, V, U)
{
        void Foo(T t,V v){...}
        V    Foo(T t){...}
        U    Foo(V v){...}
};

mixin Foo!(int, bool, float) bar; // ok, no ambiguties

bar(1, 2.0);
bool a = bar(2);
float b = bar(true);

minxin Foo!(int, int, bool) foobar; // error: T and V conflict in // ambigue function parameters, that can't overload.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867 GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E