Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should Physics::Unit objects be made immutable? #19

Open
Klortho opened this issue Apr 28, 2012 · 2 comments
Open

Should Physics::Unit objects be made immutable? #19

Klortho opened this issue Apr 28, 2012 · 2 comments

Comments

@Klortho
Copy link
Owner

Klortho commented Apr 28, 2012

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.

@jberger
Copy link
Collaborator

jberger commented Apr 29, 2012

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.

@jberger
Copy link
Collaborator

jberger commented Jun 18, 2012

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants