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