Re: Little demo of allowing basic types to implement interfaces.
On Wednesday, 4 September 2013 at 00:56:55 UTC, Rory McGuire
wrote:
I was wondering if its possible to do interfaces the way
#golang does it
but in #dlang.
Here is my first try: https://gist.github.com/rjmcguire/6431542.
Any help on making this smaller would be awesome.
Cheers,
R
Here is another example use, checking if a type can convert
itself to ubyte[]:
void main() {
int i = 0x34342343;
writebytes(i);
}
interface IRawBytes { ubyte[] bytes(); }
void writebytes(T)(T item) if (Implements!(T, IRawBytes)) {
import std.stdio : writeln;
writeln(item.bytes);
}
ubyte[] bytes(ref int i) {
ubyte* ptr;
ptr = cast(ubyte*)i;
return ptr[0..i.sizeof];
}
In the above example you get a nice error message if int does not
have the bytes ufcs function.
missing: ubyte[] int.bytes()
int, does not implement interface: traits.IRawBytes
traits.d(18): Error: template traits.writebytes does not match
any function template declaration. Candidates are:
...
Re: Little demo of allowing basic types to implement interfaces.
On Wednesday, 4 September 2013 at 06:26:08 UTC, Rory McGuire wrote: On Wednesday, 4 September 2013 at 00:56:55 UTC, Rory McGuire wrote: I was wondering if its possible to do interfaces the way #golang does it but in #dlang. Here is my first try: https://gist.github.com/rjmcguire/6431542. Any help on making this smaller would be awesome. Cheers, R Here is another example use, checking if a type can convert itself to ubyte[]: You can play with it here: http://dpaste.dzfl.pl/d7a727fd I still need to implement the part that checks aggregates.
Re: Little demo of allowing basic types to implement interfaces.
yes, it does seem to break if the Implements template func is in a different module to the free standing func. hmph, how to get around that. On Wed, Sep 4, 2013 at 9:04 AM, Tobias Pankrath tob...@pankrath.net wrote: On Wednesday, 4 September 2013 at 00:56:55 UTC, Rory McGuire wrote: I was wondering if its possible to do interfaces the way #golang does it but in #dlang. Here is my first try: https://gist.github.com/**rjmcguire/6431542https://gist.github.com/rjmcguire/6431542 . Any help on making this smaller would be awesome. Cheers, R Will this break, if I implement the free standing functions in a different module that is not in scope of the Implements! template?
Re: Little demo of allowing basic types to implement interfaces.
On Wednesday, 4 September 2013 at 08:44:45 UTC, Rory McGuire wrote: yes, it does seem to break if the Implements template func is in a different module to the free standing func. hmph, how to get around that. I don't think it is possible. You can possibly have several modules with free standing functions with same signature which will match UFCS - how one may determine in general case which one to check against? Only way is to locally clone imports from the scope `Implements` is called from and I am not aware of any mechanism to do it. Well, one can always switch to string mixins of course and invade caller scope but that is not clean by any means.
Re: Little demo of allowing basic types to implement interfaces.
On Wednesday, 4 September 2013 at 08:56:10 UTC, Rory McGuire wrote: A template should get evaluated in the calling context. No, in D templates use declaration scope (unless they are template mixins).
Re: Little demo of allowing basic types to implement interfaces.
thanks, yes, I just found that in TDPL. knew it was templates but forgot about template mixins. Do you know how to get a default parameter like __MODULE__ or __LINE__ to be used from the calling site? I've tried but I think my DMD is broken because it doesn't even work when I subclass Exception(). On Wed, Sep 4, 2013 at 11:02 AM, Dicebot pub...@dicebot.lv wrote: On Wednesday, 4 September 2013 at 08:56:10 UTC, Rory McGuire wrote: A template should get evaluated in the calling context. No, in D templates use declaration scope (unless they are template mixins).
Re: Little demo of allowing basic types to implement interfaces.
On Wednesday, 4 September 2013 at 09:23:44 UTC, Rory McGuire wrote: thanks, yes, I just found that in TDPL. knew it was templates but forgot about template mixins. Do you know how to get a default parameter like __MODULE__ or __LINE__ to be used from the calling site? I've tried but I think my DMD is broken because it doesn't even work when I subclass Exception(). Special tokens like __LINE__ in default parameters are evaluated at the call site: http://dpaste.dzfl.pl/f7b9dfcf It does not help though, because you don't need __MODULE__ of the call site, you need list of modules it has imported in exact call scope.
Re: Little demo of allowing basic types to implement interfaces.
Thanks, the exact example is exceptions. Was working really late the day
that it wasn't working :D my bad. The following is what I was after, which
I really thought I had tried.
class BaseException : Exception {
this(string s=, string file = __FILE__, int line = __LINE__) {
super(s, file, line);
}
}
On Wed, Sep 4, 2013 at 11:33 AM, Dicebot pub...@dicebot.lv wrote:
On Wednesday, 4 September 2013 at 09:23:44 UTC, Rory McGuire wrote:
thanks, yes, I just found that in TDPL. knew it was templates but forgot
about template mixins.
Do you know how to get a default parameter like __MODULE__ or __LINE__ to
be used from the calling site?
I've tried but I think my DMD is broken because it doesn't even work when
I
subclass Exception().
Special tokens like __LINE__ in default parameters are evaluated at the
call site: http://dpaste.dzfl.pl/f7b9dfcf
It does not help though, because you don't need __MODULE__ of the call
site, you need list of modules it has imported in exact call scope.
Re: Little demo of allowing basic types to implement interfaces.
I have a basic solution but it can't handle basic types LOL! you have to
typedef them so that moduleName!T works.
and then the functions have to be declared in the same module as the type.
Or alternatively you have to specify the module to use e.g.
Implements!(T,MyInterface, mymodule).
http://dpaste.dzfl.pl/cff0ca5a
I had to hard code the module name because dmd segfaults if you use
__MODULE__ in the contraint. Both references to asdf should be changed to
the module you are using.
On Wed, Sep 4, 2013 at 11:48 AM, Rory McGuire rjmcgu...@gmail.com wrote:
Thanks, the exact example is exceptions. Was working really late the day
that it wasn't working :D my bad. The following is what I was after, which
I really thought I had tried.
class BaseException : Exception {
this(string s=, string file = __FILE__, int line = __LINE__) {
super(s, file, line);
}
}
On Wed, Sep 4, 2013 at 11:33 AM, Dicebot pub...@dicebot.lv wrote:
On Wednesday, 4 September 2013 at 09:23:44 UTC, Rory McGuire wrote:
thanks, yes, I just found that in TDPL. knew it was templates but forgot
about template mixins.
Do you know how to get a default parameter like __MODULE__ or __LINE__ to
be used from the calling site?
I've tried but I think my DMD is broken because it doesn't even work
when I
subclass Exception().
Special tokens like __LINE__ in default parameters are evaluated at the
call site: http://dpaste.dzfl.pl/f7b9dfcf
It does not help though, because you don't need __MODULE__ of the call
site, you need list of modules it has imported in exact call scope.
Re: Little demo of allowing basic types to implement interfaces.
On Wednesday, 4 September 2013 at 10:33:26 UTC, Rory McGuire wrote: I have a basic solution but it can't handle basic types LOL! you have to typedef them so that moduleName!T works. Of course it can't, built-in types don't have any owning module, those are not symbols. Why would you want to care about basic types anyway?
Re: Little demo of allowing basic types to implement interfaces.
yip, :) can't think of a reason except it was interesting. wish dmd didn't segfault when I used __MODULE__. on the plus side the requirement for a non basic type is the same requirement that #golang has on its interfaces. On Wed, Sep 4, 2013 at 12:48 PM, Dicebot pub...@dicebot.lv wrote: On Wednesday, 4 September 2013 at 10:33:26 UTC, Rory McGuire wrote: I have a basic solution but it can't handle basic types LOL! you have to typedef them so that moduleName!T works. Of course it can't, built-in types don't have any owning module, those are not symbols. Why would you want to care about basic types anyway?
Re: specd - write more expressive unit tests
It would be nice to have something like
result.must.not.be!(42);
So, have a look at 'assertOp':
http://d.puremagic.com/issues/show_bug.cgi?id=4653
How can a user of your code add matchers, for example, to check
for elements or attributes in XML? (Without having to change your
code.) The hidden 'MatchStatement' makes the code easy to use but
seems to make it hard to extend. You could add a second
('matcher') parameter to 'must', but then you have to switch from
'.' to '('...')':
result.must(haveTag(root));
By the way: Does the color output work on Windows?
Here is what I do to color the unit-test results:
https://github.com/linkrope/dunit/blob/master/dunit/color.d
Re: Little demo of allowing basic types to implement interfaces.
On 2013-09-04 13:01, Rory McGuire wrote: yip, :) can't think of a reason except it was interesting. wish dmd didn't segfault when I used __MODULE__. on the plus side the requirement for a non basic type is the same requirement that #golang has on its interfaces. Do you have a module declaration? -- /Jacob Carlborg
Re: Little demo of allowing basic types to implement interfaces.
Thanks! a module declaration gets around that one. http://dpaste.dzfl.pl/cff0ca5a line 21 On Wed, Sep 4, 2013 at 1:18 PM, Jacob Carlborg d...@me.com wrote: On 2013-09-04 13:01, Rory McGuire wrote: yip, :) can't think of a reason except it was interesting. wish dmd didn't segfault when I used __MODULE__. on the plus side the requirement for a non basic type is the same requirement that #golang has on its interfaces. Do you have a module declaration? -- /Jacob Carlborg
Re: Little demo of allowing basic types to implement interfaces.
On 2013-09-04 13:57, Rory McGuire wrote: Thanks! a module declaration gets around that one. http://dpaste.dzfl.pl/cff0ca5a line 21 I think this should already be fixed in git HEAD. -- /Jacob Carlborg
Re: specd - write more expressive unit tests
On Tuesday, 3 September 2013 at 06:36:20 UTC, Jacob Carlborg
wrote:
On 2013-09-02 21:03, jostly wrote:
specd is a DSL library allowing you to write more expressive
unit tests.
It is inspired by projects like specs2 and ScalaTest from the
Scala world.
Example:
unittest {
describe(a string)
.should(have a length property,
foo.length.must.equal(3));
}
Features:
* DSL for expressing unit tests as specifications
* Verify with must instead of assert
* Report successful / failed tests using green / red paradigm
Available as a dub dependency (specd) or from
https://github.com/jostly/specd
Comments and suggestions for improvement are welcome!
I've been working on something similar myself.
https://github.com/jacob-carlborg/dspec
Narrowly avoided nameclash there. :) Good to see others thinking
along the same lines.
I'm working on a new syntax using UDA's, shown here:
https://github.com/jacob-carlborg/phobos/blob/serialization/std/serialization/tests/array.d
Looks interesting. I hadn't heard of the UDA's before, they seem
quite powerful from a brief glance.
Re: specd - write more expressive unit tests
On Wednesday, 4 September 2013 at 11:06:45 UTC, linkrope wrote:
It would be nice to have something like
result.must.not.be!(42);
So, have a look at 'assertOp':
http://d.puremagic.com/issues/show_bug.cgi?id=4653
How can a user of your code add matchers, for example, to check
for elements or attributes in XML? (Without having to change
your code.) The hidden 'MatchStatement' makes the code easy to
use but seems to make it hard to extend. You could add a second
('matcher') parameter to 'must', but then you have to switch
from '.' to '('...')':
result.must(haveTag(root));
By the way: Does the color output work on Windows?
Here is what I do to color the unit-test results:
https://github.com/linkrope/dunit/blob/master/dunit/color.d
Thanks for the feedback and the pointers - I think they're all
good ideas. I'll look into making the necessary adjustments.
Re: specd - write more expressive unit tests
On 2013-09-04 19:38, jostly wrote: Looks interesting. I hadn't heard of the UDA's before, they seem quite powerful from a brief glance. Very simple but very powerful. It's basically way to tag symbols with values/types. -- /Jacob Carlborg
FewDee: A library for 2D game prototyping
Hello, FewDee is an incomplete, experimental, mostly 2D, library focused on games prototyping. The official Mercurial repository is here: https://bitbucket.org/lmb/fewdee And there is a Git mirror here: https://github.com/lmbarros/FewDee This is work in progress. It is usable(*), but still needs lots of improvements. (*) I used an early version of FewDee in a prototype that worked even in a public demonstration ;-) I wasn't afraid of using D any features in FewDee, so I used (and even misused) lots of associative arrays, delegates, GC'ed memory... it might be interesting to see how it will behave in more demanding applications. My plan now is to stop working directly on FewDee; instead, I intend to actually use it in a few more game prototypes. Then, I'll use this experience to further guide the library evolution. Lastly, this is my first sizable D project, so destroy with kindness ;-) Cheers, LMB
