Make Object::IsFoo const.

Make Object::IsFoo const.

Removed a few useless const_casts on the way.

[Michael Starzinger, 2014-06-23 20:10:27]

Just one comment.

https://codereview.chromium.org/351573002/diff/1/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/351573002/diff/1/src/objects.h#newcode1686
src/objects.h:1686: INLINE(Heap* GetHeap() const);
Is there a particular system or reason behind which functions suddenly became
"INLINE" instead of "inline". Do any measurements say that one or the other is
better? If not, then I vote for stripping this from the change and keep this
(and all the occurrences below) as they were.

https://codereview.chromium.org/351573002/diff/1/src/objects.h#newcode1819
src/objects.h:1819: INLINE(double value() const);
Especially this one looks pretty random at first glance.

[danno, 2014-06-23 20:22:00]

Sven, could you please elaborate on the motivation of this CL? I understand that
we play fast and loose with const all over the place, but at first blush, it
seems like it's just local code churn that's not really solving any fundamental
problem?

[Sven Panne, 2014-06-24 06:10:24]

https://codereview.chromium.org/351573002/diff/1/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/351573002/diff/1/src/objects.h#newcode1686
src/objects.h:1686: INLINE(Heap* GetHeap() const);
On 2014/06/23 20:10:27, Michael Starzinger wrote:
> Is there a particular system or reason behind which functions suddenly became
> "INLINE" instead of "inline". Do any measurements say that one or the other is
> better? If not, then I vote for stripping this from the change and keep this
> (and all the occurrences below) as they were.

The system was simply: Change every signature where I've added 'const' from
'inline' to 'INLINE(...)'. I don't have any strong opinions about that, I'm
quite sure that we could totally outline more than 90% of everything marked
inline/INLINE, anyway. What's especially ugly though is that we have 3 levels of
inlining: None, hopefully and forcefully. :-P

I'll change this and the ones below back.

https://codereview.chromium.org/351573002/diff/1/src/objects.h#newcode1819
src/objects.h:1819: INLINE(double value() const);
On 2014/06/23 20:10:27, Michael Starzinger wrote:
> Especially this one looks pretty random at first glance.

Rationale: See above.

[Sven Panne, 2014-06-24 06:26:08]

On 2014/06/23 20:22:00, danno wrote:
> Sven, could you please elaborate on the motivation of this CL? I understand
that
> we play fast and loose with const all over the place, but at first blush, it
> seems like it's just local code churn that's not really solving any
fundamental
> problem?

It *is* resolving a fundamental problem: 'const' entities are at the core of
many STL and STL-like APIs, so we would have a const_cast hell all over the
place when we try to incorporate more of them into v8. The problem at hand is
the introduction of stream-like standard interfaces (avoiding our 6 confusing
and inflexible ways of doing things in this area), where you want to pass
objects by const refs. The more we rely on standard APIs, the more valuable
const-correctness will become. Furthermore, I regard 'const' as highly valuable
documentation for the programmer. Note that it doesn't really help the compiler,
see http://www.gotw.ca/gotw/081.htm.

Note that I've already drawn a line: Our verifiers should be const, too, but
this is not very important (internal uses only), so I've cut off the wave of
changes via 2 const_casts at that point. I'm slightly masochistic when it comes
to code quality, but not that much. ;-)

[Sven Panne, 2014-06-24 07:13:59]

Changed back the controversial INLINEs to inline, PTAL...

[Michael Starzinger, 2014-06-24 08:50:25]

LGTM on the technical side of the change.