Aconcagua Measurement Library - BaseUnits Storage

What's the best practice for storing basic blocks?

Let's say I want to have a mile. So I am implementing Number>>#miles

, but what is the implementation?

The problem is: (2 * (BaseUnit named: 'mile')) ~= (2 * (BaseUnit named: 'mile'))

so it seems that the base unit in the mile should be single.

So, I would have something like:

Number>>#miles
    ^ self * Mile uniqueInstance

      

Am I on the right track, or can you think of a better way?

+1


source to share


2 answers


Yes, the base unit per mile should be single, you can take a look at the Chalten structure that Aconcagua uses, specifically the TimeUnitsGlobal class. For the Number part of Chalten, this is done like this:

Number>>#daysMeasure
    ^TimeUnits day with: self

      



Although I have a problem with how it's done there, because after that I can't find a way to use Fuel with units like this.

+1


source


units are not singletons, but they use the original # = to see if two units are the same, and the default implementation # = checks the C # ID ==, but it can be overridden if needed. The reason I did this is because I thought it was the most general implementation. The easiest way to use them is to store units in global variables, so you can define:

Smalltalk at: #Mile put: (BaseUnit named: "mile" etc etc).

And then you can do 2 * Mile witch makes a lot of sense because ... it's like "knowing a mile is global"

Another way to do it is as Chalten does. That is, to have a class that knows each unit and you can access them with messages like "TimeUnits day"



The idea is not to create a class per unit which doesn't make any sense ... Another possibility: 1) change # = to Unit and use the uni name to check if two devices are equal 2) Subclass BaseUnit and do 1 ): -)

If you have fuel problems, it is because you are not storing the root object that every block knows, but once you do, the problem should be resolved.

Hernan.

+2


source







All Articles