Module-based programming

[John Colvin]

On Friday, 26 July 2013 at 13:11:33 UTC, JS wrote:
> On Friday, 26 July 2013 at 11:58:13 UTC, John Colvin wrote:
>> On Friday, 26 July 2013 at 11:42:25 UTC, JS wrote:
>>> On Friday, 26 July 2013 at 09:12:27 UTC, Land wrote:
>>>> I'm confused when it comes to modules.
>>>>
>>>> I've read somewhere that modules are basically 'singleton
>>>> classes' and that anything that doesn't need its own state 
>>>> should
>>>> not needlessly be put inside a class.
>>>>
>>>> But what if I want to create a simple OpenGL shader object. 
>>>> Do I
>>>> create a class like this:
>>>>
>>>> class Shader
>>>> {
>>>>   // Method
>>>>   // Method
>>>>   // Method
>>>>   // Method
>>>>
>>>>   // Field
>>>>   // Field
>>>>   // Field
>>>> }
>>>>
>>>> Or do I have a structure that I operate on via module 
>>>> methods?
>>>> (C-style, basically)
>>>>
>>>> struct Shader
>>>> {
>>>>   // Field
>>>>   // Field
>>>>   // Field
>>>> }
>>>>
>>>> // Method
>>>> // Method
>>>> // Method
>>>> // Method
>>>>
>>>> It's probably clear to you guys, but I'm stumped.
>>>>
>>>> Thanks for any answers
>>>
>>> Non-member methods require you to pass the object you want to 
>>> modify... do you really want to do all that extra typing? 
>>> It's your choice... you wanna program in C or C++?
>>
>> Is it really extra typing? Depending on how you format your 
>> code, you might just be swapping a '.' for a ','
>>
>> Also, we have UFCS (universal function call syntax): "foo(x, 
>> y, z)" can be written as "x.foo(y, z)"
>
> But what about protection semantics? Access to this? 
> Properties? Virtual functions?

There are lots of good reasons to use methods instead of free 
functions, I'm just saying that having to explicitly pass the 
object to the function isn't a particularly big one, especially 
in D.