Making CompileType a Value object.

Making CompileType a Value object.
Committed: https://code.google.com/p/dart/source/detail?r=18937

[Vyacheslav Egorov (Google), 2013-02-23 00:31:43]

LGTM!

Thanks, I was actually planning to address this next week.

[srdjan, 2013-02-23 00:58:45]

Committed patchset #2 manually as r18937 (presubmit successful).

[Florian Schneider, 2013-02-25 11:18:20]

https://codereview.chromium.org/12315063/diff/5001/runtime/vm/intermediate_la...
File runtime/vm/intermediate_language.h (right):

https://codereview.chromium.org/12315063/diff/5001/runtime/vm/intermediate_la...
runtime/vm/intermediate_language.h:133: 
This introduces additional unnecessary dependencies, i.e. whenever adding a
field to CompileType, both have to be updated. Why duplicate the default
behavior of both the copy constructor and the assignment object?

[srdjan, 2013-02-25 17:30:36]

https://codereview.chromium.org/12315063/diff/5001/runtime/vm/intermediate_la...
File runtime/vm/intermediate_language.h (right):

https://codereview.chromium.org/12315063/diff/5001/runtime/vm/intermediate_la...
runtime/vm/intermediate_language.h:133: 
On 2013/02/25 11:18:20, Florian Schneider wrote:
> This introduces additional unnecessary dependencies, i.e. whenever adding a
> field to CompileType, both have to be updated. Why duplicate the default
> behavior of both the copy constructor and the assignment object?

What do you suggest as alternative? Implicit copy constructors should not be
used (see Google style guide).

[Florian Schneider, 2013-02-25 18:33:41]

On 2013/02/25 17:30:36, srdjan wrote:
>
https://codereview.chromium.org/12315063/diff/5001/runtime/vm/intermediate_la...
> File runtime/vm/intermediate_language.h (right):
> 
>
https://codereview.chromium.org/12315063/diff/5001/runtime/vm/intermediate_la...
> runtime/vm/intermediate_language.h:133: 
> On 2013/02/25 11:18:20, Florian Schneider wrote:
> > This introduces additional unnecessary dependencies, i.e. whenever adding a
> > field to CompileType, both have to be updated. Why duplicate the default
> > behavior of both the copy constructor and the assignment object?
> 
> What do you suggest as alternative? Implicit copy constructors should not be
> used (see Google style guide).

In most classes we disable both anyway. There are only few places where we
actually need a copy constructor (e.g. class Location, CompileType, some
iterator classes).

I think a comment saying that the default implementation does the right thing in
such a case would be enough.