You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One issue that I struggled with while designing this module is the distinction between Unit and Scalar. They are very similar in many respects.
Related to this was my worry about the ability to redefine named units, which would then change the results of unit expressions. But I still thought it would be desirable for users to be able to define units in a stepwise way; e.g first specifying a length, then dividing by some time unit, etc. Back then, I thought that meant that the unit objects had to be mutable (actually, back then, I don't think I even knew the word "mutable").
This would mean that all of the Unit methods like add, divide, recip, etc. would return newly minted objects, instead of changing $self.
One motivation for this change is that it would remove the ugly distinction that's now required between anonymous and named unit objects.
The text was updated successfully, but these errors were encountered:
I do like the idea of returning newly minted objects I guess. For another point of reference you might want to look at http://p3rl.org/Math::Units::PhysicalValue . For some time I was using both P::U and this module in MooseX::Types::NumUnit. I ended up deciding on P::U but the other has its merits too, we can learn from it.
This really does need to be thought about. I have been looking into making the whole system object oriented, mostly so that more than one set of definitions may be used by different modules (#13). Further, then separate parsers could be used (perhaps one could read mjd's unittab)
One issue that I struggled with while designing this module is the distinction between Unit and Scalar. They are very similar in many respects.
Related to this was my worry about the ability to redefine named units, which would then change the results of unit expressions. But I still thought it would be desirable for users to be able to define units in a stepwise way; e.g first specifying a length, then dividing by some time unit, etc. Back then, I thought that meant that the unit objects had to be mutable (actually, back then, I don't think I even knew the word "mutable").
This would mean that all of the Unit methods like add, divide, recip, etc. would return newly minted objects, instead of changing $self.
One motivation for this change is that it would remove the ugly distinction that's now required between anonymous and named unit objects.
The text was updated successfully, but these errors were encountered: