Module-based programming

[Rikki Cattermole]

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

Personally I have a few rules with deciding between a class and a 
struct. A struct contains either data or functions (for global 
grouping them) although I'm sure somebody will say performance 
wise that could be bad.
A class contains both data and methods to manipulate it.

With regards to free functions for classes I look at it this way.
If it needs the internal state it should probably be a method. If 
not probably external.
All required methods also should be on the class. These should be 
not creating new instances of said class as well.

Oh and a nice syntax for those free functions is with.

with(instance) {
}

So instead of typing instance.m, m will suffice.