www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - First project: questions on how-to, and on language features

reply Alex Vincent <ajvincent gmail.com> writes:
Source code:
https://alexvincent.us/d-language/samples/intervalmap-rev1.d.txt

After reading Ali Çehreli's book, "Programming in D", I wrote 
this little sample up as a starting point for my explorations 
into D.  I've long admired the D language, but I've never 
actually tried to write practical code in D.

So I wrote this little sample up in dlangide, and as I was going, 
I realized I had quite a few questions.

(1) It's not clear how to specify certain parts of a module or 
library as non-exportable.  Is that possible?  Is it desirable?  
(It's not that important, yet, but still...)

(2) In the unittest code, I have a block that I want to rewrite 
using assertThrown, but I can't figure out from either the book 
or the website the correct usage.  What's the right way to 
specify a StringException with a particular message I expect to 
receive?

(3) How do I actually create a library in dub?  How does dub 
determine what files to build?

(4) How should the scope(exit) and scope(failure) guard 
statements intermix with preconditions and postconditions?

(5) My append() function has a postcondition that currently 
depends on debug-only members of the class being set in the 
precondition.  This seems artificial - not the part about setting 
these variables in the precondition, but having the variables 
defined on the class to begin with.  If they were defined only 
for the lifetime of the function's execution, starting in the 
precondition, this would be more natural.  Is there a Right Way 
to define function-only debug variables for use in 
postconditions?  If not, would this be a valid use-case to 
consider amending the language specification to clarify?

(6) Would someone please review my sample code and offer 
feedback?  :-)

(7) Naming:  This code is the start of a port of a mini-library I 
wrote in JavaScript which I called "ObjectRange".  However, in 
Phobos, the term "Range" has a very different meaning - in fact, 
almost the opposite meaning of what this code does.  I asked for 
a better name in the D IRC channel, and someone suggested 
Interval, based on the mathematical definition of the word.  
IntervalMap seemed more accurate, since there is a payload to 
each interval.  Does the name make sense in the context?

(8) Is there a similar, more mature library out there which tries 
to achieve what I'm doing here?  I'm rather surprised I didn't 
see anything like it in the standard library...
Jan 23
next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Sunday, 24 January 2016 at 06:07:13 UTC, Alex Vincent wrote:
 (1) It's not clear how to specify certain parts of a module or 
 library as non-exportable.  Is that possible?  Is it desirable?
  (It's not that important, yet, but still...)
Yes, definitely. By default symbols in a module are `public`, but you can mark them as `private`. These aren't accesible from other modules: module test; void foo() { } // public, because there's no annotation private bar() { } // private void bar2() { } // public again private: // everything from here on is private void bla() { } void blubb() { }
 (2) In the unittest code, I have a block that I want to rewrite 
 using assertThrown, but I can't figure out from either the book 
 or the website the correct usage.  What's the right way to 
 specify a StringException with a particular message I expect to 
 receive?
Here's the relevant documentation: https://dlang.org/phobos/std_exception.html#.assertThrown https://dlang.org/phobos/std_exception.html#.collectExceptionMsg `assertThrown()` doesn't allow to check the message directly, it can only check whether a particular type of exception has been thrown: assertThrown!StringException(throw new StringException("test")); Instead, you can use `collectExceptionMsg()` to check both the message and the exception type: assert( collectExceptionMsg!StringException(throw ...) == "test" );
 (4) How should the scope(exit) and scope(failure) guard 
 statements intermix with preconditions and postconditions?
Pre- and postconditions are supposed to run before you enter the function, or after you left it, respectively. Therefore, and scope() blocks in the function body would already have completed when the postcondition is entered. OTOH, scope() blocks only run if control flow has passed through them. In a precondition, this hasn't happened yet, and therefore they will not run. If you mean whether you can use scope() blocks in pre- and postconditions, yes, you can. The will then run when you leave the pre- and postcondition. But usually, pre- and postconditions only consist of very little code that's not supposed to do any serious work, so they are less likely to be used there. Or, looking at it from a different angle: A scope() block only runs at the end of the lexical scope / block it appears in. Pre- and postconditions are not part of the function body, or vice versa. Therefore, see above.
 (5) My append() function has a postcondition that currently 
 depends on debug-only members of the class being set in the 
 precondition.  This seems artificial - not the part about 
 setting these variables in the precondition, but having the 
 variables defined on the class to begin with.  If they were 
 defined only for the lifetime of the function's execution, 
 starting in the precondition, this would be more natural.  Is 
 there a Right Way to define function-only debug variables for 
 use in postconditions?  If not, would this be a valid use-case 
 to consider amending the language specification to clarify?
I'm not an expert in contract programming, but as I see it, your precondition doesn't actually check anything, you're kinda abusing them as preparation for your postcondition. That's likely not the way it's supposed to be. I see what you're trying to achieve, and I believe it's legitimate to check for... You could either just move the assert()s into the function body just before the end, where you have access to the local variables (but you could easily miss an early return), or put them into a scope(exit) block (but then you could accidentally check it too early). Your best bet here is probably to check it in a unittest, although they are for a slightly different purpose, strictly speaking.
Jan 24
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 01/24/2016 04:26 AM, Marc Schütz wrote:

 (2) In the unittest code, I have a block that I want to rewrite using
 assertThrown, but I can't figure out from either the book or the
 website the correct usage.  What's the right way to specify a
 StringException with a particular message I expect to receive?
Here's the relevant documentation: https://dlang.org/phobos/std_exception.html#.assertThrown https://dlang.org/phobos/std_exception.html#.collectExceptionMsg
Here is another link for completeness: http://ddili.org/ders/d.en/unit_testing.html#ix_unit_testing.assertThrown,%20std.exception Ali
Jan 25
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Sun, 24 Jan 2016 06:07:13 +0000, Alex Vincent wrote:

 Source code:
 https://alexvincent.us/d-language/samples/intervalmap-rev1.d.txt
There is no documentation, so I have no idea what you're trying to achieve here. So your questions about why this isn't in Phobos, whether there are any other libraries that do this, and whether there's a way to simplify your contracts are impossible for me to answer. I notice you're using identifiers that start with double underscores. I'd recommend not making a habit of that. The compiler generates symbols for some things, and those symbols start with a double underscore. For example: class Foo { this(int i) {} void __ctor(int i) {} } auto f = new Foo(1); This produces an error like: dubleuscore.d(13): Error: dubleuscore.Foo.__ctor called with argument types (int) matches both: dubleuscore.d(4): dubleuscore.Foo.this(int i) and: dubleuscore.d(7): dubleuscore.Foo.__ctor(int i) The compiler can add more such identifiers without warning, which could break your code in interesting ways.
 After reading Ali Çehreli's book, "Programming in D", I wrote this
 little sample up as a starting point for my explorations into D.  I've
 long admired the D language, but I've never actually tried to write
 practical code in D.
 
 So I wrote this little sample up in dlangide, and as I was going,
 I realized I had quite a few questions.
 
 (1) It's not clear how to specify certain parts of a module or library
 as non-exportable.  Is that possible?  Is it desirable? (It's not that
 important, yet, but still...)
As Marc mentioned, the 'private' keyword. You can use it directly: private int f; int g; // implicitly public in blocks: private { int h; int i; } int j; // implicitly public or label style: private: int k; int m; public int n; // have to explicitly mark anything else public That's all module-local. If you need to restrict things to your package, you can use the 'package' keyword, which functions identically. All these syntax variants work everywhere. I find it handy, for instance, to write my code like: class Foo { private { // fields go here } // everything else is generally public } Aside from that, if you do not add a documentation comment to something, it will not be mentioned at all in the generated documentation. This makes it difficult for users to discover, in case you really need something to be public but don't want people to use it. But using 'package' rather than 'public' will usually suffice in those cases.
 (3) How do I actually create a library in dub?  How does dub determine
 what files to build?
I believe Dub includes all files by default.
 (4) How should the scope(exit) and scope(failure) guard statements
 intermix with preconditions and postconditions?
Marc answered this, but while we're on the topic of preconditions, I notice your usage of enforce: enforce(index > upperEdge, new StringException("index must be greater than upperEdge")); The idiom in use in Phobos is: enforce!StringException(index > upperEdge, "index must be greater than upperEdge");
Jan 24
parent Alex Vincent <ajvincent gmail.com> writes:
On Sunday, 24 January 2016 at 18:52:41 UTC, Chris Wright wrote:
 There is no documentation, so I have no idea what you're trying 
 to achieve here. So your questions about why this isn't in 
 Phobos, whether there are any other libraries that do this, and 
 whether there's a way to simplify your contracts are impossible 
 for me to answer.
Objections have been noted and (hopefully) corrected: https://github.com/ajvincent/d-experiments/blob/master/IntervalMap/source/intervalmap.d I'm going for the concept of versioning data - first a single value, and then members of an array. (I haven't implemented the versioning of arrays yet.) That's why I said it's an inverse of Phobos ranges: each iteration call to a range could give you a different value. Here, several versions can point to one value. Feedback is still most strongly welcomed.
Feb 02