www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Type keyword ?

reply "Matthew Craig" <mwcraig btinternet.com> writes:
I'm still getting familiar with D so hopefully I'm not missing anything
obvious. What
I'm proposing is a keyword type only allowable in interfaces that basically
means
any type. I know what your thinking we want D to be a strongly typed
language and
this would negate type checking. Well not really as if I understand
correctly interfaces
are similar to pure virtual classes in that they have no implementation
therefore type
checking isn't necessary. And as I mentioned it would only be legal within
interfaces.

Consider the following code (forgive the use of pointers I'm still
converting to D ;-))

// interface

interface IGfx
{
    byte* getScreen();
}

// sdl interface

alias SDL_Surface* Surface

class ISDL : IGfx
{
    SDL_Surface* screen;
    byte* getScreen()
    {
        return cast(byte*)screen;
    }
}

// gfx

class Gfx : IGfx
{
    byte* getScreen()
    {
        return currInterface.getScreen();
    }
}

// main

gfx.FlipScreen(cast(Surface*)gfx.getScreen());


Now lets rewrite it with a type keyword to see the difference

// interface

interface IGfx
{
    type getScreen();
}

// sdl interface

alias SDL_Surface Surface

class ISDL : IGfx
{
    SDL_Surface* screen;
    SDL_Surface* getScreen()
    {
        return screen;
    }
}

// gfx

class Gfx : IGfx
{
    Surface* getScreen()
    {
        return currInterface.getScreen();
    }
}

// main

gfx.FlipScreen(gfx.getScreen());

Much clearer I think you'd agree

The pros as I see it are

a. Gain flexibility without losing any type checking
b. Cleaner syntax
c. Easier to add new interfaces

The cons are

a. Perhaps too flexible, consider that as you switched interfaces the
    return type of getScreen could change from a struct to a byte pointer.
    Still wouldn't have thought that's a really big deal.

Any thoughts ?
Oct 08 2004
next sibling parent reply Ant <duitoolkit yahoo.ca> writes:
On Sat, 09 Oct 2004 01:26:34 +0100, Matthew Craig wrote:

 
 Any thoughts ?

yes: you got it all wrong that's why you need it. alternativelly to your design: Screen is an interface that declares the flip method you'll have classes on sdl, ogl and dx packages that implement the Screen interface. you'll have methods on sdl, ogl and dx classes that return a Screen interface. the end result would be gfx.getScreen().flip(); "Much clearer I think you'd agree" :) I see your level of abstraction as inadequate, and the reponsabilities on the wrong places. why you still have the "currentInterface"?!... didn't we tell you to get rid of it? and don't use "alias", it's use should be retricted. in fact - in this case - replace alias by interface and you're almost there. Ant PS just trying to help (I tried before and always failed over the internet :(, but ask my coleagues: it works live, in person...)
Oct 07 2004
parent reply "Matthew Craig" <mwcraig btinternet.com> writes:
Ok how would your design switch between interfaces i.e.

gfx.getScreen() // is that getScreen for OpenGL, SDL etc.

that's why I still have currInterface plus it prevents me having
to do

gfx.getInterface.foo();

all the time and instead I can just say

gfx.foo();

And how does your design return values don't you still have the same
problems

Surface screen = gfx.getScreen().getSurface();

a. So how would you declare Surface without using alias I thought
    it was just like typedef.
b. And how do you get around the problem of

interface blah
{
    // don't know what type surface will be so use byte*
    byte* getSurface();
}

class foo : blah
{
    fooSurface* getSurface() {}; // error getSurface not implemented
    // could change to byte* but then need casting
}

Sorry if I'm being thick perhaps you could do a quick code snippet to
explain what you mean.

Thanks

"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.10.08.04.00.25.923513 yahoo.ca...
 On Sat, 09 Oct 2004 01:26:34 +0100, Matthew Craig wrote:

 Any thoughts ?

yes: you got it all wrong that's why you need it. alternativelly to your design: Screen is an interface that declares the flip method you'll have classes on sdl, ogl and dx packages that implement the Screen interface. you'll have methods on sdl, ogl and dx classes that return a Screen interface. the end result would be gfx.getScreen().flip(); "Much clearer I think you'd agree" :) I see your level of abstraction as inadequate, and the reponsabilities on the wrong places. why you still have the "currentInterface"?!... didn't we tell you to get rid of it? and don't use "alias", it's use should be retricted. in fact - in this case - replace alias by interface and you're almost there. Ant PS just trying to help (I tried before and always failed over the internet :(, but ask my coleagues: it works live, in person...)

Oct 09 2004
parent reply "Matthew Craig" <mwcraig btinternet.com> writes:
As Sjoerd has just pointed out I think templates are the answer to most of
these
problems as I mentioned I've been taught to be very wary of templates and
never
used them in production, however it sounds like D's template implementation
is
pretty solid.

"Matthew Craig" <mwcraig btinternet.com> wrote in message
news:ck8dkg$dkc$1 digitaldaemon.com...
 Ok how would your design switch between interfaces i.e.

 gfx.getScreen() // is that getScreen for OpenGL, SDL etc.

 that's why I still have currInterface plus it prevents me having
 to do

 gfx.getInterface.foo();

 all the time and instead I can just say

 gfx.foo();

 And how does your design return values don't you still have the same
 problems

 Surface screen = gfx.getScreen().getSurface();

 a. So how would you declare Surface without using alias I thought
     it was just like typedef.
 b. And how do you get around the problem of

 interface blah
 {
     // don't know what type surface will be so use byte*
     byte* getSurface();
 }

 class foo : blah
 {
     fooSurface* getSurface() {}; // error getSurface not implemented
     // could change to byte* but then need casting
 }

 Sorry if I'm being thick perhaps you could do a quick code snippet to
 explain what you mean.

 Thanks

 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.10.08.04.00.25.923513 yahoo.ca...
 On Sat, 09 Oct 2004 01:26:34 +0100, Matthew Craig wrote:

 Any thoughts ?

yes: you got it all wrong that's why you need it. alternativelly to your design: Screen is an interface that declares the flip method you'll have classes on sdl, ogl and dx packages that implement the Screen interface. you'll have methods on sdl, ogl and dx classes that return a Screen interface. the end result would be gfx.getScreen().flip(); "Much clearer I think you'd agree" :) I see your level of abstraction as inadequate, and the reponsabilities on the wrong places. why you still have the "currentInterface"?!... didn't we tell you to get rid of it? and don't use "alias", it's use should be retricted. in fact - in this case - replace alias by interface and you're almost there. Ant PS just trying to help (I tried before and always failed over the internet :(, but ask my coleagues: it works live, in person...)


Oct 09 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Sat, 09 Oct 2004 11:31:53 +0100, Matthew Craig wrote:

 As Sjoerd has just pointed out I think templates are the answer

No, this is a simple school like case where the OO paradigma fits perfectly.
 Ok how would your design switch between interfaces i.e.

 gfx.getScreen() // is that getScreen for OpenGL, SDL etc.


again I see it differently from you. your Gfx class implementes the IGfx interface and just delegates to the currentInterface object. that's wrong. you should have one (or as many as you like simultaneasly) IGfx instanciated from any of the IGfx implementators. It's wrong to control which implementation is used from inside the IGfx object. you should have some other class to control it.
 that's why I still have currInterface plus it prevents me having
 to do

 gfx.getInterface.foo();

 all the time and instead I can just say

 gfx.foo();

 And how does your design return values don't you still have the same
 problems


gfx *IS* the IGfx, does not contain a IGfx in your case it's both. See my answer to your other question. to switch implementations you just create a new IGfx instance from another IGfx implementator.
 Surface screen = gfx.getScreen().getSurface();

 a. So how would you declare Surface without using alias I thought
     it was just like typedef.
 b. And how do you get around the problem of

 interface blah
 {
     // don't know what type surface will be so use byte*
     byte* getSurface();
 }


wrong idea, it should be: interface Surface { Surface flip(); int getWidth(); int getHeight(); void whatever(); } interface Screen : Surface { void whatever(); } (of course I don't know the details of Surface and Screen so that might be completly of) we don't know how Surface is implemented at the IGfx level. the IGfx only knows that surface can be fliped, has a width and a height and can do whatever. You don't expose the details of surface outside of it's implementators. don't go with the templates, it's wrong here. don't use templates until you fully get the OO with interfaces, then do who you feel it's better.
 class foo : blah
 {
     fooSurface* getSurface() {}; // error getSurface not implemented
     // could change to byte* but then need casting
 }


if you need to use alias and cast something went wrong somewhere.
 Sorry if I'm being thick perhaps you could do a quick code snippet to
 explain what you mean.


try to see if that enough, again don't use templates for this case. Ant
Oct 09 2004
next sibling parent reply "Matthew Craig" <mwcraig btinternet.com> writes:
"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.10.09.15.43.14.581136 yahoo.ca...
 On Sat, 09 Oct 2004 11:31:53 +0100, Matthew Craig wrote:

 As Sjoerd has just pointed out I think templates are the answer

No, this is a simple school like case where the OO paradigma fits perfectly.
 Ok how would your design switch between interfaces i.e.

 gfx.getScreen() // is that getScreen for OpenGL, SDL etc.


again I see it differently from you. your Gfx class implementes the IGfx interface and just delegates to the currentInterface object. that's wrong. you should have one (or as many as you like simultaneasly) IGfx instanciated from any of the IGfx implementators. It's wrong to control which implementation is used from inside the IGfx object. you should have some other class to control it.

So what your saying is you should have IGfx gfx; IGfx gfxSdl = new ISDL(); IGfx gfxOpenGL = new IOpenGL(); and to switch you assign to gfx i.e. gfx = gfxSdl; fair enough and you agree another class could control the switching right, well surely it would look like the one I've got that your not impressed with enum GfxInterfaces { OpenGL } class Gfx { // Pointer to selected interface IGfx currInterface; // Available interfaces IGfx availableInterfaces[GfxInterfaces.max]; // Constructor this() { for ( int i = 0; i < GfxInterfaces.max; i++ ) { switch(i) { case GfxInterfaces.OpenGL : { availableInterfaces[i] = new IOpenGL(); } break; default : break; } } } void SwitchInterface(GfxInterfaces desiredInterface) { currInterface = availableInterfaces[desiredInterface]; } } I think what's thrown you is that i had class Gfx : IGfx which I agree is unnecessary if not plain wrong.
 Surface screen = gfx.getScreen().getSurface();

 a. So how would you declare Surface without using alias I thought
     it was just like typedef.
 b. And how do you get around the problem of

 interface blah
 {
     // don't know what type surface will be so use byte*
     byte* getSurface();
 }


wrong idea, it should be: interface Surface { Surface flip(); int getWidth(); int getHeight(); void whatever(); } interface Screen : Surface { void whatever(); } (of course I don't know the details of Surface and Screen so that might be completly of) we don't know how Surface is implemented at the IGfx level. the IGfx only knows that surface can be fliped, has a width and a height and can do whatever. You don't expose the details of surface outside of it's implementators. don't go with the templates, it's wrong here. don't use templates until you fully get the OO with interfaces, then do who you feel it's better.

I hear what your saying here about it being a text book case of OO design, encapsulate the surface and you should never need to get hold of it yourself and muck about with it (hence breaking the encapsulation) however the problem I find with text book design is it often causes frustration in the real world. I totally agree that the surface should be encapsulated away and you should try not to mess with it directly as much as possible, however theres a good chance at some point your going to want to just get hold of the raw data. Imagine your using someone elses library lets say it handles buffers. It's a great library and you've used it for a while and all is well until you suddenly wish it had another function. If it's not an open source project your only option is to request the author adds the function to his library however if it has a function such as getRawBuffer then at least you can pull out the raw data work on it in your function and put it back. If your an OO purist you'll no doubt argue all day that this is a terrible thing to do and you should find a better way of doing it, but it works and D being a practical language for practical people should allow you to do it without too much fuss IMHO after all that's why you have pointers it's a case of don't use them unless you have to but they're there if you really need them. In which case I think my original suggestion may still be valid.
 class foo : blah
 {
     fooSurface* getSurface() {}; // error getSurface not implemented
     // could change to byte* but then need casting
 }


if you need to use alias and cast something went wrong somewhere.

You still haven't mentioned what's so bad about using alias it just looks like typedef to me *shrugs*
 Sorry if I'm being thick perhaps you could do a quick code snippet to
 explain what you mean.


try to see if that enough, again don't use templates for this case.

I think I got your point ;-)
 Ant

Oct 09 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Sat, 09 Oct 2004 21:17:05 +0100, Matthew Craig wrote:

 fair enough and you agree another class could control the switching
 right,

of course.
 I think what's thrown you is that i had
 
 class Gfx : IGfx
 
 which I agree is unnecessary if not plain wrong.

agree.
 Imagine your using someone elses library lets say it handles buffers.
 It's a great
 library and you've used it for a while and all is well until you
 suddenly wish it had
 another function.

doesn't that shows your design to be faulty or incomplete? ;) but I agree the raw structures should be made available some how.
 If your an OO purist

oh!... I see you're new here :)
 
 I think I got your point ;-)

I think you did! Ant
Oct 09 2004
next sibling parent reply John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
 
If your an OO purist

oh!... I see you're new here :)

Ha Ha HA! :D Funny, Ant! Matthew, it may take awhile to get used to Ant's... err... style of critiquing, but Ant's okay. ;-) Although, I think Ant's going to have to eventually drop his notorious "English-is-my-second-language" excuse for being so direct with people. I'm beginning to think that he has become somewhat adept with the language now. :) Later, John
Oct 09 2004
next sibling parent "Matthew Craig" <mwcraig btinternet.com> writes:
I've worked with people much more 'direct' he didn't even swear ;-)

I'm all for good constructive criticism it's how you separate the chaff
from the wheat so to speak.

"John Reimer" <brk_6502 NOSP_AM.yahoo.com> wrote in message
news:ck9ugl$1cc9$1 digitaldaemon.com...
If your an OO purist

oh!... I see you're new here :)

Ha Ha HA! :D Funny, Ant! Matthew, it may take awhile to get used to Ant's... err... style of critiquing, but Ant's okay. ;-) Although, I think Ant's going to have to eventually drop his notorious "English-is-my-second-language" excuse for being so direct with people. I'm beginning to think that he has become somewhat adept with the language now. :) Later, John

Oct 09 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
John Reimer schrieb:

 oh!... I see you're new here :)

Ha Ha HA! :D Funny, Ant!

:>
 Matthew, it may take awhile to get used to Ant's... err... style of 
 critiquing, but Ant's okay. ;-)

I haven't seen Ant being wrong on such questions. In fact, any runtime discrimination using switch or if statements is very much slower than function pointers, and OO provides a very nice wrapper for these. So OO is very applicable where performance engeneering comes into play, to a certain degree of course.
 Although, I think Ant's going to have to eventually drop his notorious 
 "English-is-my-second-language" excuse for being so direct with people. 
  I'm beginning to think that he has become somewhat adept with the 
 language now. :)

I think it doesn't really matter. I live in a country where i day for day speak in my third (or was it fourth?) language, and almost noone notices that i could be a foreigner. :> So i started thinking up excuses for myself, but i don't think they limit themselves to my personality. * I have bipolar disorder. Leave me alone! ELSE I SCRREAM! * Hey, me comes from south! Let us *hug* each other and then nothing was ever wrong anyway! * I have multiple sclerosis. What did you just say? What's up anyway? Don't hesitate to add more. In fact, over these all years i have not simply been too harsh to some people, i have even offended some due to some strange condition of mine combined with ignorance. May those forgive me. -eye/photoAllergics
Oct 13 2004
prev sibling parent "Matthew Craig" <mwcraig btinternet.com> writes:
 Imagine your using someone elses library lets say it handles buffers.
 It's a great
 library and you've used it for a while and all is well until you
 suddenly wish it had
 another function.

doesn't that shows your design to be faulty or incomplete? ;) but I agree the raw structures should be made available some how.

Language design is always a balance between too little or too much flexibility. C++ has loads of flexibility (too much) which is the cause of its popularity and ultimately its (probable) demise. However in aiming to reduce c++'s flexibility care needs to be taken not to overshoot the mark. I'm not saying D is one way or the other yet, I've not used it long enough to even begin to judge. As you can see from my initial post it is possible however you have to make quite a mess to do it. IMHO the type keyword I suggested would prevent you being penalised for doing this and give it a touch more flexibility. Just a thought.
 If your an OO purist

oh!... I see you're new here :)

I sure am, there's an interesting line in my Game Programming Gems book that goes "Game programmers are a slightly different breed than the typical application programmer, because their work is always expected to be cutting edge, pushing hardware constraints to the limit, game developers tend to be much more willing to bend or even break traditional programming design rules." Guess that rules me out of the purist camp ;-)
 I think I got your point ;-)

I think you did! Ant

Oct 09 2004
prev sibling parent reply Sjoerd van Leent <svanleent wanadoo.nl> writes:
Ant wrote:
 On Sat, 09 Oct 2004 11:31:53 +0100, Matthew Craig wrote:
 
 
As Sjoerd has just pointed out I think templates are the answer

No, this is a simple school like case where the OO paradigma fits perfectly.

I am not quite convinced that the SDL_Surface and Surface types are the same type. I think it is imported from a header file or something like that. If so, You can't use the standard OO paradigma (although it seems the most obvious way). At the other hand, it is possible to wrap up SDL_Surface and Surface in their own wrapper classes. This would reinstantiate the use of full blown OO programming. Were I previously mentioned thay (be it lazy) templated behaviour, it is very well possible to rewrite it to full OO: ----- *PREVIOUS* ----- interface Graphics(T) { T getScreen(); } class SDL : Graphics(SDLSurface) { SDLSurface screen; SDLSurface getScreen() {...} } class OpenGL : Graphics(Surface) { Surface screen; Surface getScreen() {...} } ----- *NEW* ----- interface Graphics { Surface getScreen(); } interface Surface { // ... generic surface methods } class SDLSurface : Surface { SDL_Surface instanceSDL; // ... overridden surface methods from the interface } class OpenGLSurface : Surface { OpenGL_Surface instanceOpenGL; // ... overridden surface methods from the interface } class SDL : Graphics { Surface screen; this() { screen = new SDLSurface(); } Surface getScreen() {...} } class OpenGL : Graphics { Surface screen; this() { screen = new OpenGLSurface(); } Surface getScreen() {...} } There are even much better solutions to this problem, but it is proven that both template programming and full OO programming can be used. It's up to you though. Regards, Sjoerd
Oct 09 2004
parent Ant <duitoolkit yahoo.ca> writes:
On Sat, 09 Oct 2004 22:56:11 +0200, Sjoerd van Leent wrote:

 Ant wrote:
 On Sat, 09 Oct 2004 11:31:53 +0100, Matthew Craig wrote:
 
 
As Sjoerd has just pointed out I think templates are the answer

No, this is a simple school like case where the OO paradigma fits perfectly.

I am not quite convinced that the SDL_Surface and Surface types are the same type.

It doesn't look that bad, in fact...
 
 There are even much better solutions to this problem,

where, where, how?
 but it is proven 
 that both template programming and full OO programming can be used. It's 
 up to you though.

yes, and now he has a choice. Ant
Oct 09 2004
prev sibling next sibling parent reply Sjoerd van Leent <svanleent wanadoo.nl> writes:
Matthew Craig wrote:
 I'm still getting familiar with D so hopefully I'm not missing anything
 obvious. What
 I'm proposing is a keyword type only allowable in interfaces that basically
 means
 any type. I know what your thinking we want D to be a strongly typed
 language and
 this would negate type checking. Well not really as if I understand
 correctly interfaces
 are similar to pure virtual classes in that they have no implementation
 therefore type
 checking isn't necessary. And as I mentioned it would only be legal within
 interfaces.
 

Use class/interface templates: # interface Graphics(T) { # T getScreen(); # } # # class SDL : Graphics(SDLSurface) { # SDLSurface screen; # SDLSurface getScreen() {...} # } # # class OpenGL : Graphics(Surface) { # Surface screen; # Surface getScreen() {...} # } This should make the thing better to read. And it is legal D. One last note, please use the D convention. It makes terrible reading with all those useless underscores and prefixes/postfixes. Regards, Sjoerd
Oct 09 2004
parent "Matthew Craig" <mwcraig btinternet.com> writes:
I was thinking a combination of interface and template might be the answer
I'll give it a go. I've never really got stuck into templates before because
the
c++ STL was never considered 'fit for production' where I've worked however
D's looks much better.

Sorry about not using D convention (old habits die hard) however I didn't
use
any underscores the only ones used were from the SDL library which I can't
change ;-) I imagine there will be a fair bit of 'hybrid' C/D code around
until
more libraries are ported to D.

Thanks

"Sjoerd van Leent" <svanleent wanadoo.nl> wrote in message
news:ck8cd4$cm0$1 digitaldaemon.com...
 Matthew Craig wrote:
 I'm still getting familiar with D so hopefully I'm not missing anything
 obvious. What
 I'm proposing is a keyword type only allowable in interfaces that


 means
 any type. I know what your thinking we want D to be a strongly typed
 language and
 this would negate type checking. Well not really as if I understand
 correctly interfaces
 are similar to pure virtual classes in that they have no implementation
 therefore type
 checking isn't necessary. And as I mentioned it would only be legal


 interfaces.

Use class/interface templates: # interface Graphics(T) { # T getScreen(); # } # # class SDL : Graphics(SDLSurface) { # SDLSurface screen; # SDLSurface getScreen() {...} # } # # class OpenGL : Graphics(Surface) { # Surface screen; # Surface getScreen() {...} # } This should make the thing better to read. And it is legal D. One last note, please use the D convention. It makes terrible reading with all those useless underscores and prefixes/postfixes. Regards, Sjoerd

Oct 09 2004
prev sibling parent reply "Lloyd Dupont" <ld NewsAccount.galador.net> writes:
just out of curiosity, is it private work or would you share it one day?
loks pretty .... mesmerizing? (I'm not sure it's the right word, I'm only a 
poor french in a remote country)

"Matthew Craig" <mwcraig btinternet.com> wrote in message 
news:ck7b7l$2kh0$1 digitaldaemon.com...
 I'm still getting familiar with D so hopefully I'm not missing anything
 obvious. What
 I'm proposing is a keyword type only allowable in interfaces that 
 basically
 means
 any type. I know what your thinking we want D to be a strongly typed
 language and
 this would negate type checking. Well not really as if I understand
 correctly interfaces
 are similar to pure virtual classes in that they have no implementation
 therefore type
 checking isn't necessary. And as I mentioned it would only be legal within
 interfaces.

 Consider the following code (forgive the use of pointers I'm still
 converting to D ;-))

 // interface

 interface IGfx
 {
    byte* getScreen();
 }

 // sdl interface

 alias SDL_Surface* Surface

 class ISDL : IGfx
 {
    SDL_Surface* screen;
    byte* getScreen()
    {
        return cast(byte*)screen;
    }
 }

 // gfx

 class Gfx : IGfx
 {
    byte* getScreen()
    {
        return currInterface.getScreen();
    }
 }

 // main

 gfx.FlipScreen(cast(Surface*)gfx.getScreen());


 Now lets rewrite it with a type keyword to see the difference

 // interface

 interface IGfx
 {
    type getScreen();
 }

 // sdl interface

 alias SDL_Surface Surface

 class ISDL : IGfx
 {
    SDL_Surface* screen;
    SDL_Surface* getScreen()
    {
        return screen;
    }
 }

 // gfx

 class Gfx : IGfx
 {
    Surface* getScreen()
    {
        return currInterface.getScreen();
    }
 }

 // main

 gfx.FlipScreen(gfx.getScreen());

 Much clearer I think you'd agree

 The pros as I see it are

 a. Gain flexibility without losing any type checking
 b. Cleaner syntax
 c. Easier to add new interfaces

 The cons are

 a. Perhaps too flexible, consider that as you switched interfaces the
    return type of getScreen could change from a struct to a byte pointer.
    Still wouldn't have thought that's a really big deal.

 Any thoughts ?

 

Oct 09 2004
parent "Matthew Craig" <mwcraig btinternet.com> writes:
I'm just doing it for fun because I want to explore the D language, however
if I get to a point where I feel the community would find what I'm doing
useful
I would happily contribute it back. I wouldn't hold your breath though I've
still got lots to learn ;-)

"Lloyd Dupont" <ld NewsAccount.galador.net> wrote in message
news:ck8kl3$i31$1 digitaldaemon.com...
 just out of curiosity, is it private work or would you share it one day?
 loks pretty .... mesmerizing? (I'm not sure it's the right word, I'm only

 poor french in a remote country)

 "Matthew Craig" <mwcraig btinternet.com> wrote in message
 news:ck7b7l$2kh0$1 digitaldaemon.com...
 I'm still getting familiar with D so hopefully I'm not missing anything
 obvious. What
 I'm proposing is a keyword type only allowable in interfaces that
 basically
 means
 any type. I know what your thinking we want D to be a strongly typed
 language and
 this would negate type checking. Well not really as if I understand
 correctly interfaces
 are similar to pure virtual classes in that they have no implementation
 therefore type
 checking isn't necessary. And as I mentioned it would only be legal


 interfaces.

 Consider the following code (forgive the use of pointers I'm still
 converting to D ;-))

 // interface

 interface IGfx
 {
    byte* getScreen();
 }

 // sdl interface

 alias SDL_Surface* Surface

 class ISDL : IGfx
 {
    SDL_Surface* screen;
    byte* getScreen()
    {
        return cast(byte*)screen;
    }
 }

 // gfx

 class Gfx : IGfx
 {
    byte* getScreen()
    {
        return currInterface.getScreen();
    }
 }

 // main

 gfx.FlipScreen(cast(Surface*)gfx.getScreen());


 Now lets rewrite it with a type keyword to see the difference

 // interface

 interface IGfx
 {
    type getScreen();
 }

 // sdl interface

 alias SDL_Surface Surface

 class ISDL : IGfx
 {
    SDL_Surface* screen;
    SDL_Surface* getScreen()
    {
        return screen;
    }
 }

 // gfx

 class Gfx : IGfx
 {
    Surface* getScreen()
    {
        return currInterface.getScreen();
    }
 }

 // main

 gfx.FlipScreen(gfx.getScreen());

 Much clearer I think you'd agree

 The pros as I see it are

 a. Gain flexibility without losing any type checking
 b. Cleaner syntax
 c. Easier to add new interfaces

 The cons are

 a. Perhaps too flexible, consider that as you switched interfaces the
    return type of getScreen could change from a struct to a byte


    Still wouldn't have thought that's a really big deal.

 Any thoughts ?


Oct 09 2004