On 07/26/2013 08:33 AM, Land wrote:

> What about inheritance and interfaces,
> though? Am I supposed to put all the interface/inherited methods into
> the object

At least technically, yes. There is no other way for interfaces and function overriding.

> and all the other, utility methods, as free functions?

Some people think that as long as a function can be implemented as a free-standing function, then it should be a free-standing function. My earlier canTravel() is a good example. (Aside: In D, there is no free-standing function, they are all at least parts of modules.)

Others think that any function closely related to a type should be a member function. Interestingly, canTravel() is good example here as well. :) Since most modern cars do report estimated distance the car can go with the remaining fuel, canTravel() can also be designed to be a member function.

Ali

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.