On Jun 1, 2011, at 8:11 PM, James Robinson wrote:
> On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen 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 observable st
On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen 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 that meaning
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 wrote:
> I know that Ahem is safe to
On Thu, Jun 2, 2011 at 12:38 AM, Maciej Stachowiak wrote:
>
> Looks to me like these fulfill the requirement of "do we ever use const
> pointers to these objects". So the next step is to fix up const member
> functions that inappropriately return non-const pointers to objects in the
> same tree (o
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* nextTextBo
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 :
> I think we should add a rule like "a const member function should
> never return non-c
I thought the whole point of Ahem was to avoid those problems.
Adam
On Thu, Jun 2, 2011 at 1:29 AM, Hao Zheng wrote:
> 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 flo
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
http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium-linux/fast/b
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 c
On Thu, Jun 2, 2011 at 1:02 PM, Geoffrey Garen 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
> needed -- oth
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 implement
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 coul
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 AP
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 su
15 matches
Mail list logo