Hi everybody,
I'm currently in the process of building a scriptable plugin using
NPAPI/NPRuntime,
and I'm trying to make the thing work with both ordinary property access and
array
access.
To this end, I have the following check in the implementation of my
hasProperty() / getProperty()
if
I saw another patch get rejected today because of switch statement
indentation. We discussed this last week, and I saw a lot of support
for my proposal of indenting case labels from their switch. But the
discussion did not end in resolution. To summarize, here are the
options mentioned:
Hi WebKit folks,
If you are not using git for WebKit, you can stop reading now.
With many helps from bunch of people, I added support of decoding images in
git binary patches to svn-apply and bugzilla's pretty printer. This means
you can post git format patches to bugzilla even if your patch
On Wednesday 09 December 2009 10:26:24 am Chris Marrin wrote:
I saw another patch get rejected today because of switch statement
indentation. We discussed this last week, and I saw a lot of support
for my proposal of indenting case labels from their switch. But the
discussion did not end in
On Dec 9, 2009, at 4:41 AM, Eddy Bruël wrote:
However, when I trace my plugin, I notice that NPN_IdentifierIsString()
always returns true, even if I do an array access. It looks like the array
index gets converted to a string before it is passed to any of my callbacks.
This doesn't seem
On Dec 9, 2009, at 7:26 AM, Chris Marrin wrote:
I saw another patch get rejected today because of switch statement
indentation. We discussed this last week, and I saw a lot of support
for my proposal of indenting case labels from their switch. But the
discussion did not end in
On Dec 9, 2009, at 8:13 AM, Adam Treat wrote:
On Wednesday 09 December 2009 10:26:24 am Chris Marrin wrote:
I saw another patch get rejected today because of switch statement
indentation. We discussed this last week, and I saw a lot of support
for my proposal of indenting case labels from
On Dec 9, 2009, at 9:41 AM, Maciej Stachowiak wrote:
On Dec 9, 2009, at 7:26 AM, Chris Marrin wrote:
I saw another patch get rejected today because of switch statement
indentation. We discussed this last week, and I saw a lot of
support for my proposal of indenting case labels from
On Wednesday 09 December 2009 01:03:23 pm Chris Marrin wrote:
What is wrong with keeping the current rule?
As I pointed out in the previous thread, I feel like it makes the code
harder to read, and got several responses of agreement. Also most of
the switch statements in the code currently
On 08.12.2009, at 23:44, Darin Fisher wrote:
Sounds right to me since it mirrors the solution used to enable XHR
from workers.
Sounds good to me, too.
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Dec 9, 2009, at 10:57 AM, Adam Treat wrote:
Ok, well FWIW I disagree that the current rule makes things hard to read and
I do not like the idea of changing it. I object on the same grounds as the
other recent styling change proposals as well as substantively that it makes
anything
On Wednesday 09 December 2009 02:04:07 pm Darin Adler wrote:
On Dec 9, 2009, at 10:57 AM, Adam Treat wrote:
Ok, well FWIW I disagree that the current rule makes things hard to read
and I do not like the idea of changing it. I object on the same grounds
as the other recent styling change
On Wed, Dec 9, 2009 at 10:11 AM, Chris Marrin cmar...@apple.com wrote:
1) Case labels always have the same indentation as their switch (today's
rule)
If excessive indentation really is that big of a concern (which I don't
think it is) I would rather see the current rule (rule 1) used.
On Dec 9, 2009, at 11:25 AM, Adam Treat wrote:
That speaks negatively to the real world value of the rule IMHO.
A lot of the code predates the rule, so I wouldn’t judge the effectiveness of
the rule too harshly.
-- Darin
___
webkit-dev mailing
Looked at the bots again this morning and filed:
https://bugs.webkit.org/show_bug.cgi?id=32339 about a media test which
still seems to be failing on SL
https://bugs.webkit.org/show_bug.cgi?id=32340 about the Windows
fast/js/method-check.html crash.
-eric
On Tue, Dec 8, 2009 at 1:24 PM, Nikolas
On Dec 9, 2009, at 10:11 AM, Chris Marrin wrote:
On Dec 9, 2009, at 9:41 AM, Maciej Stachowiak wrote:
I meant 4 spaces from the switch (i.e. 2 additional spaces from the
case label).
switch (x) {
case foo: {
fooFunc();
}
case bar:
barFunc();
}
Ok, the example above seems to be
Hello webkit folks!
This is just a heads-up that I'm working on implementing access to the
SQL database from worker context [I see
https://bugs.webkit.org/show_bug.cgi?id=22725, now that I look for
it]. I'll give a quick outline as to how I'm doing it, and if you
want to tell me that there's a
Hi Adam,
On Dec 9, 2009, at 11:25 AM, Adam Treat wrote:
Yep, that does distinguish. That being said, my personal preference
would be
either to keep the current rule and change the code to meet it or
even better
just eliminate the rule altogether since the community hasn't been
following
On Dec 9, 2009, at 1:02 PM, Maciej Stachowiak wrote:
That's my thinking on the matter, perhaps others have other opinions.
Perhaps no surprise to the rest of you, but I agree with every word Maciej said.
-- Darin
___
webkit-dev mailing list
For what it's worth, I completely agree as well.
Can we take this and put it in the style guide? That way it's perfectly
clear to people under what circumstances we would consider changing it and
we can even cite specific reason numbers in the discussions?
On Wed, Dec 9, 2009 at 1:05 PM, Darin
On Wed, Dec 9, 2009 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
That's my thinking on the matter, perhaps others have other opinions.
Regards,
Maciej
+1. Very sound rules of thumb; please preserve them somewhere! FWIW,
these are basically the principles we followed at Oracle; the only
Hi,
Kim and I have been looking into DOM/JavaScript touch event support (see
https://bugs.webkit.org/show_bug.cgi?id=32114 ). After some research we
concluded that the best option for the interface is the de-facto standard
shipped by the iPhone, Android and Palm-Pre.
So we took the BSD
On Wednesday 09 December 2009 04:02:07 pm Maciej Stachowiak wrote:
I have thought over your comments about not changing the style
guidelines at a whim.
I think you make a very good point: the most important thing about the
style guidelines is that there is one way to do things, and that's
On Wed, Dec 9, 2009 at 12:58 PM, Eric Uhrhane er...@chromium.org wrote:
I've pulled the database-related members out of Document and made a
new class for them, DatabaseManager. An instance of that is owned by
each ScriptExecutionContext. There are two flavors,
DocumentDatabaseManager and
At first glance these meta-guidelines seem fine. If they are going
to be written down somewhere, a couple minor comments:
On Dec 9, 2009, Maciej Stachowiak wrote:
I think something like
the following should be our meta-guidelines for when to change the
style guide:
It would be good to
On Wednesday 09 December 2009 07:03:51 pm Peter Kasting wrote:
But even what is trivial is a judgement call. In general people don't
disagree about issues where they believe disagreement is a waste of time.
...
And I don't. Who is right? More importantly, how will you prevent us from
On Wed, Dec 9, 2009 at 4:47 PM, Adam Treat tr...@kde.org wrote:
On Wednesday 09 December 2009 07:03:51 pm Peter Kasting wrote:
And I don't. Who is right? More importantly, how will you prevent us
from
starting this debate on a bug?
I won't? If you as a reviewer consider the indentation
On Wed, Dec 9, 2009 at 4:11 PM, Dmitry Titov dim...@chromium.org wrote:
On Wed, Dec 9, 2009 at 12:58 PM, Eric Uhrhane er...@chromium.org wrote:
I've pulled the database-related members out of Document and made a
new class for them, DatabaseManager. An instance of that is owned by
each
Thanks for the link to the prototype code!
If I understand it right and the DatabaseManager can not have any other
relationship with ScriptExecutionContext but 1-1 and their lifetime is the
same then it's not clear to me what benefit could be had by effectively
splitting a class in two. The fact
29 matches
Mail list logo
