Module-based programming

JS js.mdnq at gmail.com
Fri Jul 26 06:11:31 PDT 2013


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?


More information about the Digitalmars-d-learn mailing list