On Jun 1, 2011, at 8:11 PM, James Robinson wrote:
On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen gga...@apple.com wrote:
I agree that const should be used for logical constness. The rule should
not be merely doesn't alter any data members of this object but rather
does not alter
On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen gga...@apple.com wrote:
So, perhaps the real style question we should answer is when to use const
pointers / references, since the answer to when to use const member
functions will follow from it.
What are some good examples of existing code
Actually, even the same Ahem font will be rendered differently on
different platform, depending on the font drawing library, the
anti-aliasing algorithm, subpixel, tiny float-point calculation diff
on different arch.
On Thu, Jun 2, 2011 at 3:30 AM, Eric Seidel e...@webkit.org wrote:
I know that
I think we should add a rule like a const member function should
never return non-const pointer/reference.
I have seen the problem in many places that you can get non-const
reference on a const object.
For example, InlineTextBox has
InlineTextBox* prevTextBox() const;
InlineTextBox*
Similar thing: doc-frame()-document().
The solution should be defining both const and non-const members:
const Frame* frame() const { reutrn m_frame; }
Frame* frame() { return m_frame; }
2011/6/2 Yong Li yong.li.web...@gmail.com:
I think we should add a rule like a const member function should
I thought the whole point of Ahem was to avoid those problems.
Adam
On Thu, Jun 2, 2011 at 1:29 AM, Hao Zheng zheng...@chromium.org wrote:
Actually, even the same Ahem font will be rendered differently on
different platform, depending on the font drawing library, the
anti-aliasing algorithm,
Perhaps, but in practice, it's not enough. Here's an ahem pixel test that
is slightly different on Mac and Chromium Linux:
http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/fast/block/basic/010-expected.png
Responding to a few comments at once:
I'm curious if there was a specific patch or piece of code that lead you to
send this email out - perhaps we make a better decision about whether to
change our approach with more concrete examples of problems the current
situation has caused or is
On Thu, Jun 2, 2011 at 1:02 PM, Geoffrey Garen gga...@apple.com wrote:
Perhaps we could at least encourage const-correctness for newly-written
classes? By this I mean both adherence to the logical-constness rules you
stated earlier as well as not adding non-const accessors and members unless
Does anyone have an opinion on this Web Storage spec bug? The input of the
WebKit community is desired. And probably Safari and Chrome folks in
particular, if opinions differ.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that
As of http://trac.webkit.org/changeset/87948, we have a new, less
painful way to write WebCore tests: the window.internals object.
Similar to window.layoutTestController, this object is only exposed
when DRT runs. Unlike window.layoutTestController, you don't have to
wade in every port's
I'm concerned that implementing this will only encourage more use of
localStorage. The API is very poor because it requires synchronous IO and
synchronization between browser contexts, which may live on different
threads. (Note: Chrome does not implement the required synchronization.)
If we
I'd advise commenting right in the w3c bugzilla, but if you don't feel like
making an extra account I can copy in the below remarks for you.
- Maciej
On Jun 2, 2011, at 8:54 PM, Darin Fisher wrote:
I'm concerned that implementing this will only encourage more use of
localStorage. The API
I think that these shortcomings are also strengths. A synchronous localStorage
is a drop-in replacement for cookies, which is a good thing to offer, and to
encourage. Practically, if it's only cookies vs. IndexedDB (or SQL Database),
I'd realistically choose the former for most code, and I'm
14 matches
Mail list logo
