Module-based programming

Ali Çehreli acehreli at yahoo.com
Fri Jul 26 08:24:02 PDT 2013


On 07/26/2013 05:13 AM, Dicebot wrote:

 > On Friday, 26 July 2013 at 09:12:27 UTC, Land wrote:
 >> struct Shader
 >> {
 >>      // Field
 >>      // Field
 >>      // Field
 >> }
 >>
 >> // Method
 >> // Method
 >> // Method
 >> // Method
 >
 > I personally favor this approach whenever possible, it fits nicely with
 > UFCS and allows to keep data type signature clean from unrelated stuff.
 > My guideline is "If something simply operates on an aggregate, make it a
 > free function. If it requires some knowledge about private aggregate
 > state and/or is something done by aggregate, make it a method".

+1

I apply the same idea in C++ as well.

Of course, the decision of whether it is a struct or class is based on 
other factors. (This is not an issue in C++ because structs and classes 
are semantically same there.)

And yes, UFCS helps with this in D. I had come up with a quick example: 
Once a Car class provides basic functionality, functions like 
canTravel() should not be members: [1]

class Car
{
     enum economy = 12.5;          // kilometers per liter (average)
     private double fuelAmount;    // liters

     this(double fuelAmount)
     {
         this.fuelAmount = fuelAmount;
     }

     double fuel() const
     {
         return fuelAmount;
     }

     // ...
}

bool canTravel(Car car, double distance)
{
     return (car.fuel() * car.economy) >= distance;
}

Ali

[1] http://ddili.org/ders/d.en/ufcs.html



More information about the Digitalmars-d-learn mailing list