On 5-3-2013 1:20, bearophile wrote:
Jos van Uden:
It depends on how you interpret it. The task describes two actions:
display and append. The question is: does the last sentence refer to
the append action or to both display and append. I choose to think it
refers to the append action because that makes more sense.
OK.
- - - - - - - - - - - -
As for http://rosettacode.org/wiki/Simple_database
You removed the struct that I used to encapsulate the functions.
Aren't these functions now exposed to other modules? I wanted
them to only be callable from main. The input validation relies
on that.
At first I had declared them all private, but then I thought it
would be convenient to put a struct around them and declare it
private. Maybe there's a better way.
D isn't a pure OOP language, it thankfully supports free functions. Generally
structs and classes shouldn't be used if they are not useful (this is well
known in the Python community). A struct with just static methods is
essentially a namespace. In D modules are namespaces, so there is less need to
wrap static functions in a struct.
In this case of the Simple database Task I think this is not a module to be
imported, because it has a main. It's a complete program (like other hundreds
of D Tasks in Rosettacode) and it's not meant to be imported. So I think
wrapping everything in a struct in this case is useless, it just increases the
indenting.
Do you agree?
I'm not attached to the struct, but it doesn't feel right to have these
functions publicly accessible. It's a matter of good coding practice.
If I import a module these functions are exposed.
