A little of coordination for Rosettacode

[Jos van Uden]

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.