Re: Default Implementation For an Interface
On 02/16/2012 04:01 AM, Kevin wrote:
I was implementing a framework and I found that I wanted two things.
- A strong set of interfaces so that I can get what I want from a
variety of sources.
- Some basic implementations of these interfaces.
For example, say I was writing a database class. I could either name the
interface Database and call the class DatabaseImplementation or
something but that is ugly. If I call the interface IDatabase, the
Database class looks nice but I need to convince users to write
functions that take IDatabases not Databases.
I was wondering if there was any way to implement a default
implementation. This way, I could create my Database interface and
classes could implement that but if you called `new Database()` you
would still get a basic database.
I thought about doing it in different modules but it just gets messier
as you have to fully qualify all of the names so both look ugly. I
though about overloading the new operator for the interface but it would
have to be final and that would mess everything up. I though about a
meathod like `Database.newDefault()` but that is messy and has no
meaning in a derived class.
I couldn't find anything about this so I was wondering what you would
recommend. Should I just pick a naming scheme?
As a user (read developer), I'd rather code to the generic interface
when possible. I like that concrete implementations looks rather long
and ugly :)
I don't think you should be worried that your users is using direct
implementations rather than the interface - their problem!
Remember that in D, interfaces can contain implementations that only
uses static methods on the interface:
interface DB {
@property string name();
// interfaces can have implementations
static DB createDefault() { return new GenericDB(); }
}
class GenericDB : DB {
@property string name() {
return generic; }
}
class MySQLDB : DB {
@property string name() {
return mysql; }
}
void main() {
assert(DB.createDefault().name == generic);
assert((new MySQLDB()).name == mysql);
}
Re: Compiling Lua for D
On Thursday, 16 February 2012 at 05:06:13 UTC, Jesse Phillips wrote: BTW, I totally recommend LuaD when interacting with lua. Thank you for the explanation. I've started with LuaD, but I kinda didn't like it, can't exactly say why. I rather want to use Lua directly for now, and maybe write my own wrapper later.
Re: Default Implementation For an Interface
On 2012-02-16 04:01, Kevin wrote:
I was implementing a framework and I found that I wanted two things.
- A strong set of interfaces so that I can get what I want from a
variety of sources.
- Some basic implementations of these interfaces.
For example, say I was writing a database class. I could either name the
interface Database and call the class DatabaseImplementation or
something but that is ugly. If I call the interface IDatabase, the
Database class looks nice but I need to convince users to write
functions that take IDatabases not Databases.
I was wondering if there was any way to implement a default
implementation. This way, I could create my Database interface and
classes could implement that but if you called `new Database()` you
would still get a basic database.
You can create an abstract class that implements some parts of the
interface. Then the user (developer) is free to choose to inherit from
the interface or the abstract class.
I thought about doing it in different modules but it just gets messier
as you have to fully qualify all of the names so both look ugly. I
though about overloading the new operator for the interface but it would
have to be final and that would mess everything up. I though about a
meathod like `Database.newDefault()` but that is messy and has no
meaning in a derived class.
I couldn't find anything about this so I was wondering what you would
recommend. Should I just pick a naming scheme?
About the naming scheme I would go for this:
interface Database {}
abstract AbstractDatabase : Database {}
class Implementation : Database {}
class Implementation2 : AbstractDatabase {}
Possibly suffix the implementations with Database.
class ImplementationDatabase : Database {}
class Implementation2Database : AbstractDatabase {}
But it feels a bit redundant with Database in the implementation name.
--
/Jacob Carlborg
Re: Default Implementation For an Interface
On Thursday, February 16, 2012 11:11:20 Jacob Carlborg wrote: You can create an abstract class that implements some parts of the interface. Then the user (developer) is free to choose to inherit from the interface or the abstract class. Which results in a classic problem that you run into in Java all the time when dealing with event-based programming (since it deals with events via interfaces). If you have a class that only really needs to implement a couple of the functions from the interface of an event listener, then you can derive from the class which implements it and gives them all empty bodies. But if you need your class to implement multiple such interfaces, you can only do that with one of them, which gets really annoying, because then you have to create a bunch of empty method bodies yourself. It's one of the classic examples where multiple inheritance would be desirable. The current situation in D is exactly the same (though, since we don't have a swing equivalent, I don't think that it's something that D programmers are frequently running into at the moment). AIUI, Java is going to be adding the ability to give interfaces default implementations such that that implementation is effectively copy-pasted into your class when you implement it and don't provide an implementation yourself (rather than the function in your class overidding it as would be the case with an abstract class). This nicely solves the event listener problem, and D doesn't have that. I assume that that's the sort of thing that the OP is looking for. Now, if you use template mixins, I believe that it's possible to use that to mixin default implementations for the functions in an interface, which should solve the problem for D. So, that's probably good enough for D without having to make it so that interface functions can have default implementations. - Jonathan M Davis
Re: Default Implementation For an Interface
On Thursday, 16 February 2012 at 10:24:44 UTC, Jonathan M Davis
wrote:
On Thursday, February 16, 2012 11:11:20 Jacob Carlborg wrote:
You can create an abstract class that implements some parts of
the
interface. Then the user (developer) is free to choose to
inherit from
the interface or the abstract class.
Which results in a classic problem that you run into in Java
all the time when dealing with event-based programming (since
it deals with events via interfaces). If you have a class that
only really needs to implement a couple of the functions from
the interface of an event listener, then you can derive from
the class which implements it and gives them all empty bodies.
But if you need your class to implement multiple such
interfaces, you can only do that with one of them, which gets
really annoying, because then you have to create a bunch of
empty method bodies yourself. It's one of the classic examples
where multiple inheritance would be desirable.
The current situation in D is exactly the same (though, since
we don't have a swing equivalent, I don't think that it's
something that D programmers are frequently running into at the
moment). AIUI, Java is going to be adding the ability to give
interfaces default implementations such that that
implementation is effectively copy-pasted into your class when
you implement it and don't provide an implementation yourself
(rather than the function in your class overidding it as would
be the case with an abstract class). This nicely solves the
event listener problem, and D doesn't have that. I assume that
that's the sort of thing that the OP is looking for.
Now, if you use template mixins, I believe that it's possible
to use that to mixin default implementations for the functions
in an interface, which should solve the problem for D. So,
that's probably good enough for D without having to make it so
that interface functions can have default implementations.
- Jonathan M Davis
BlackHole from std.typeconst can be used for that purpose.
import std.typecons;
interface A
{
void a();
int b(void* arg);
}
interface B
{
int c(string arg);
}
interface Common : A, B
{
}
class Good : BlackHole!Common
{
override int b(void* arg)
{
return 0;
}
}
void main()
{
auto g = new Good;
g.a();
auto i = g.b(null);
auto j = g.c(Hello);
}
Re: Hex floats
On 15/02/12 22:24, H. S. Teoh wrote: What's the original rationale for requiring that hex float literals must always have an exponent? For example, 0xFFi obviously must be float, not integer, so why does the compiler (and the spec) require an exponent? The syntax comes from C99.
Re: Default Implementation For an Interface
On 2012-02-16 11:23, Jonathan M Davis wrote: On Thursday, February 16, 2012 11:11:20 Jacob Carlborg wrote: You can create an abstract class that implements some parts of the interface. Then the user (developer) is free to choose to inherit from the interface or the abstract class. Which results in a classic problem that you run into in Java all the time when dealing with event-based programming (since it deals with events via interfaces). If you have a class that only really needs to implement a couple of the functions from the interface of an event listener, then you can derive from the class which implements it and gives them all empty bodies. But if you need your class to implement multiple such interfaces, you can only do that with one of them, which gets really annoying, because then you have to create a bunch of empty method bodies yourself. It's one of the classic examples where multiple inheritance would be desirable. Interfaces and abstract classes is the simple solution. If the class hierarchy is quite simple won't be a problem. It looks like it is quite simple in this case. Or one could skip the interface completely perhaps. The current situation in D is exactly the same (though, since we don't have a swing equivalent, I don't think that it's something that D programmers are frequently running into at the moment). AIUI, Java is going to be adding the ability to give interfaces default implementations such that that implementation is effectively copy-pasted into your class when you implement it and don't provide an implementation yourself (rather than the function in your class overidding it as would be the case with an abstract class). This nicely solves the event listener problem, and D doesn't have that. I assume that that's the sort of thing that the OP is looking for. Since D have delegates I would use those for event handling and not listeners. I think they are a much better fit, as long as you don't have to force the user to handle many different events on the same object. Now, if you use template mixins, I believe that it's possible to use that to mixin default implementations for the functions in an interface, which should solve the problem for D. So, that's probably good enough for D without having to make it so that interface functions can have default implementations. - Jonathan M Davis Template mixins cause their own problems. You can't overload methods with template mixins, may it's possible to get around that with aliases, I don't remember. -- /Jacob Carlborg
Re: Hex floats
On 16/02/2012 12:04, Don Clugston wrote: On 15/02/12 22:24, H. S. Teoh wrote: What's the original rationale for requiring that hex float literals must always have an exponent? For example, 0xFFi obviously must be float, not integer, so why does the compiler (and the spec) require an exponent? The syntax comes from C99. Do you mean the syntax has just been copied straight from C99 without any thought about making it more lenient? Stewart.
Re: Re: Default Implementation For an Interface
As a user (read developer), I'd rather code to the generic interface
when possible. I like that concrete implementations looks rather long
and ugly
I don't think you should be worried that your users is using direct
implementations rather than the interface - their problem!
Remember that in D, interfaces can contain implementations that only
uses static methods on the interface:
interface DB {
@property string name();
// interfaces can have implementations
static DB createDefault() { return new GenericDB(); }
}
class GenericDB : DB {
@property string name() {
return generic; }
}
class MySQLDB : DB {
@property string name() {
return mysql; }
}
void main() {
assert(DB.createDefault().name == generic);
assert((new MySQLDB()).name == mysql);
}
I see what you are saying. If it is not possible to have a default I
think I will call the interface Database and the class BasicDatabase as
that sounds intuitive.
Thanks to everyone for the help.
Re: warning: size of symbol changed
On 02/16/2012 01:32 AM, Jacob Carlborg wrote:
On 2012-02-16 03:35, Ellery Newcomer wrote:
has anyone else gotten warnings of the nature
/usr/bin/ld: Warning: size of symbol `{875charlongsymbol}' changed from
107 in multi_index.o to 99 in multi_index.o
Sounds like you should do a clean build.
it does this on a clean build.
Re: Hex floats
On 16/02/12 13:28, Stewart Gordon wrote: On 16/02/2012 12:04, Don Clugston wrote: On 15/02/12 22:24, H. S. Teoh wrote: What's the original rationale for requiring that hex float literals must always have an exponent? For example, 0xFFi obviously must be float, not integer, so why does the compiler (and the spec) require an exponent? The syntax comes from C99. Do you mean the syntax has just been copied straight from C99 without any thought about making it more lenient? Stewart. Yes. There would need to be a good reason to do so. For the case in question, note that mathematically, imaginary integers are perfectly valid. Would an imaginary integer literal be an idouble, a ifloat, or an ireal? I don't think it could be any: foor(float x) foor(double x) fooi(ifloat x) fooi(idouble x) foor(7); //ambiguous, doesn't compile fooi(7i); // by symmetry, this shouldn't compile either
Re: D for game Development
On 2/16/2012 3:32 AM, Chris Pons wrote: On Wednesday, 15 February 2012 at 15:41:02 UTC, Kiith-Sa wrote: On Wednesday, 15 February 2012 at 06:51:11 UTC, RedShift wrote: Can I use OpenGL or DirectX with D? If so, where can I find a guide to get everything setup? Derelict provides bindings for OpenGL and SDL (and many other game-related libraries) - these are used exactly the same way they are used in C/C++, so any OpenGL/SDL tutorials for C/C++ apply. Derelict has a few of its own functions that can/need to be called when initializing, described in its documentation. The current stable version of Derelict supports only OpenGL up to 2.1 and SDL 1.2, but support for OpenGL 3.0+ and SDL2 is being worked on. For the current development version, see https://github.com/aldacron/Derelict3 (Derelict moved to GitHub recently) Ok, So let me get this straight. I can use Derelict with OpenGL 3. ish, and support for 4.0 is on the way. No -ish to it :-) Up to 3.3 is fully supported. However, 3.x support was sort of hacked on to the existing framework and isn't entirely intuitive. It has to do with the way ARB extensions are reused in 3.x and how that doesn't fit well with DerelictGL's internal architecture. A recent post on the Derelict forums describes what to do. I can also use any tutorials to learn Opengl? Any tutorials for C or C++ will work just the same for D. That is really good news.
Re: D for game Development
On 2/16/2012 4:07 AM, Chris Pons wrote: I am sorry about the double post. I am in the middle of trying to install derelict following this tutorial: http://h3.gd/dmedia/?n=Tutorials.SdlGlTutorial1 However, when I get to the third step I get this error: Error 1 Error: module gl is in file 'derelict\opengl\gl.d' which cannot be read D:\Documents\Projects\Test\Test\main.d 3 I am assuming this means that gl.d can not be found. However, my derelict source files are in .../dmd2/src/ext/derelict/ Probably not a good idea to put this in the dmd directory. It makes it less easy to upgrade dmd. In my VS project under the options panel, I pointed my DMD install path to D:\Documents\Projects\DMD2 . Do I need to set the Import and Library path as well? Yes. When you compile Derelict2, .di files are generated in the import subdirectory and the libraries in the lib subdirectory. I would just pass -Iderelict-root/import on the command line, and add pragma(lib, path/to/DerelictSomething.lib or (libDerelictSomething.a) to your source modules.
Re: How to get Visual D working with Derelict2?
On 2/16/2012 5:39 AM, Chris Pons wrote: Hey everyone, I am new to D, and interested in using it with Derelict2 for game development. I plan on using Visual D, which I have installed already. I used the visual studio 2008 solution file to build the libraries and the .di files but unfortunately I do not know where to put these files once built or alternatively setup Visual D to recognize their location. Right click on your project in the Solution Explorer, select Properties, then Configuration Properties-DMD. Enter the path (absolute or relative) to your import directory (ex: if the DerelictUtil modules are in C:\foo\derelict\util, you would add C:\foo as the import path). Now select Configuration Properties-Linker and enter the libraries in Library Files. You'll need to include the path like so: C:\foo\libs\DerelictUtil.lib C:\foo\libs\DerelictGL.lib Alternatively, you can add the following to the top of your source module: pragma(lib, C:\foo\libs\DerelictUtil.lib); pragma(lib, C:\foo\libs\DerelictGL.lib); ... Makes sure to add every lib you need to link with. Lastly, how would I import these libraries in the code? You don't import libraries. You import modules. The import statement tells DMD which source modules to look in for external declarations. It has absolutely nothing to do with library files. And if the root directory for the module package is not on the import path, it won't be able to find them.
Re: Hex floats
On 02/16/2012 05:06 PM, Don Clugston wrote: On 16/02/12 13:28, Stewart Gordon wrote: On 16/02/2012 12:04, Don Clugston wrote: On 15/02/12 22:24, H. S. Teoh wrote: What's the original rationale for requiring that hex float literals must always have an exponent? For example, 0xFFi obviously must be float, not integer, so why does the compiler (and the spec) require an exponent? The syntax comes from C99. Do you mean the syntax has just been copied straight from C99 without any thought about making it more lenient? Stewart. Yes. There would need to be a good reason to do so. For the case in question, note that mathematically, imaginary integers are perfectly valid. Would an imaginary integer literal be an idouble, a ifloat, or an ireal? I don't think it could be any: foor(float x) foor(double x) fooi(ifloat x) fooi(idouble x) foor(7); //ambiguous, doesn't compile fooi(7i); // by symmetry, this shouldn't compile either static assert(is(typeof(7i)==idouble));
Re: Default Implementation For an Interface
On Thursday, February 16, 2012 13:26:59 Jacob Carlborg wrote: Since D have delegates I would use those for event handling and not listeners. I think they are a much better fit, as long as you don't have to force the user to handle many different events on the same object. Oh, I'm not necessarily arguing that using interfaces far listeners is the way to go (in fact, I agree that delegates would be much better). It's just that that's a prime example of a situation where you want default implementations for interface methods, since with single inheritance, you can't derive a class from multiple classes which give you default implementations for interface methods. Now, if you use template mixins, I believe that it's possible to use that to mixin default implementations for the functions in an interface, which should solve the problem for D. So, that's probably good enough for D without having to make it so that interface functions can have default implementations. Template mixins cause their own problems. You can't overload methods with template mixins, may it's possible to get around that with aliases, I don't remember. I thought that you could, since they can be virtual, unlike templated functions. I don't know though. It's not something that I've really had to worry about - particularly since so few of my D programs need classes, let alone interfaces (because most of my D programs are small). - Jonathan M Davis
Re: Default Implementation For an Interface
On 2012-02-16 20:05, Jonathan M Davis wrote: On Thursday, February 16, 2012 13:26:59 Jacob Carlborg wrote: Since D have delegates I would use those for event handling and not listeners. I think they are a much better fit, as long as you don't have to force the user to handle many different events on the same object. Oh, I'm not necessarily arguing that using interfaces far listeners is the way to go (in fact, I agree that delegates would be much better). It's just that that's a prime example of a situation where you want default implementations for interface methods, since with single inheritance, you can't derive a class from multiple classes which give you default implementations for interface methods. Ok, I see. I got the impression that you preferred listeners. Now, if you use template mixins, I believe that it's possible to use that to mixin default implementations for the functions in an interface, which should solve the problem for D. So, that's probably good enough for D without having to make it so that interface functions can have default implementations. Template mixins cause their own problems. You can't overload methods with template mixins, may it's possible to get around that with aliases, I don't remember. I thought that you could, since they can be virtual, unlike templated functions. I don't know though. It's not something that I've really had to worry about - particularly since so few of my D programs need classes, let alone interfaces (because most of my D programs are small). - Jonathan M Davis Note that I'm saying overload not override. -- /Jacob Carlborg
Re: Hex floats
More questions about hex floats. So we've established that hex floats have decimal exponents. So how should the following be tokenized? 0x1p1E8 Should it be tokenized as (Float: 0x1p1)(Identifier: E8), or should it be an error? T -- Не дорог подарок, дорога любовь.
Re: Hex floats
On 02/16/2012 08:36 PM, H. S. Teoh wrote:
More questions about hex floats. So we've established that hex floats
have decimal exponents. So how should the following be tokenized?
0x1p1E8
Should it be tokenized as (Float: 0x1p1)(Identifier: E8), or should it
be an error?
T
It should be tokenized into the two tokens. q{0x1p1E8} is a legal D token.
Re: Default Implementation For an Interface
On Thursday, February 16, 2012 20:17:22 Jacob Carlborg wrote: Note that I'm saying overload not override. Ah, so you did. Yes, that would probably be a problem, though aliases can probably fix it (that's how you deal with having all of the overloads for a function in the same overload set for a derived class when you only override some of them). But I haven't tried it, so I don't know. - Jonathan M Davis
Re: Default Implementation For an Interface
On 2012-02-16 22:08, Jonathan M Davis wrote: On Thursday, February 16, 2012 20:17:22 Jacob Carlborg wrote: Note that I'm saying overload not override. Ah, so you did. Yes, that would probably be a problem, though aliases can probably fix it (that's how you deal with having all of the overloads for a function in the same overload set for a derived class when you only override some of them). But I haven't tried it, so I don't know. - Jonathan M Davis I know it works with derived classes but I haven't tried it with template mixins. -- /Jacob Carlborg
split with delimiter
reading http://www.d-programming-language.org/phobos/std_array.html#split --- S[] split(S)(S s); // merge space together and Unqual!(S1)[] split(S1, S2)(S1 s, S2 delim); // do not merge delim together ? --- why the second split function do not merge delim together? how merge delim together?
Re: split with delimiter
Le vendredi 17 février 2012 à 01:33 +0100, bioinfornatics a écrit :
reading
http://www.d-programming-language.org/phobos/std_array.html#split
---
S[] split(S)(S s); // merge space together
and
Unqual!(S1)[] split(S1, S2)(S1 s, S2 delim); // do not merge delim
together ?
---
why the second split function do not merge delim together?
how merge delim together?
Code to try
--
import std.string;
import std.stdio;
import std.array;
void main( ){
string test = hi\t\tD is fun;
string test2= hi D is fun;
writeln( test.split(\t));
writeln( test2.split() );
writeln( test2.split( ) );
}
--
Result
[hi, , D is fun]
[hi, D, is, fun]
[hi, , D, is, fun]
Re: split with delimiter
On Friday, 17 February 2012 at 00:47:35 UTC, bioinfornatics wrote:
Le vendredi 17 février 2012 à 01:33 +0100, bioinfornatics a
écrit :
reading
http://www.d-programming-language.org/phobos/std_array.html#split
---
S[] split(S)(S s); // merge space together
and
Unqual!(S1)[] split(S1, S2)(S1 s, S2 delim); // do not merge
delim
together ?
---
why the second split function do not merge delim together?
how merge delim together?
Code to try
--
import std.string;
import std.stdio;
import std.array;
void main( ){
string test = hi\t\tD is fun;
string test2= hi D is fun;
writeln( test.split(\t));
writeln( test2.split() );
writeln( test2.split( ) );
}
--
Result
[hi, , D is fun]
[hi, D, is, fun]
[hi, , D, is, fun]
I was talking with bioinfornatics on IRC so I can clarify a bit
of what he's saying. std.array.split without delimiter merges
runs of adjacent whitespace. In the version where you can
specify the delimiter runs are not merged leaving empty items in
the resulting array. This is because the delimiter specifying
version just calls std.algorithm.splitter which doesn't merge
runs whereas the whitespace version of std.array.split uses its
own internal algorithm to split.
Although the delimiter specifiable version's documentation
doesn't say it would merge runs, one would assume it'd behave
like its whitespace only cousin.
Either the docs should be clarified or the function should be
changed to work like the other version (I prefer the latter
solution).
Regards,
Brad Anderson
Flushing denormals to zero
After seeing this interesting thread: http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x Do you know if there's a simple way to perform _MM_SET_FLUSH_ZERO_MODE in D? According to Agner that operation is not needed on Sandy Bridge processors, but most CPUs around are not that good: http://www.agner.org/optimize/blog/read.php?i=142 Bye, bearophile
