On Mon, Jan 6, 2014 at 11:49 PM, Geoffrey Garen gga...@apple.com wrote:
(2) ApplyStyleCommand.cpp:
auto children = elementChildren(*dummySpanAncestor);
for (auto child = children.begin(), end = children.end(); child !=
end; ++child) {
*if
If I had to describe this algorithm in English, I’d say, “Collect and
retain all the [auto] from the list of parsed parameters.” I think that
explanation would be stronger if “[auto]” were a concrete noun.
The variable and the function are both named pattern and I would use that as
the
04 янв. 2014 г., в 9:51, Darin Adler da...@apple.com написал(а):
There are so many other things which you can’t see when reading a line of C++
code, which I think is a good thing — part of what makes C++ a high level
language. To create a straw man, imagine what it would be like if we had
On Jan 6, 2014, at 10:03 AM, Alexey Proskuryakov a...@webkit.org wrote:
As auto facilitates search-replace-don't-read refactoring
I was talking about refactoring without changing function names. I don’t
understand your example.
— Darin
___
On Jan 6, 2014, at 13:49 , Geoffrey Garen
gga...@apple.commailto:gga...@apple.com wrote:
Let me try to clarify with two more motivating examples:
(1) Nodes.cpp:
FunctionParameters::FunctionParameters(ParameterNode* firstParameter, unsigned
size)
: m_size(size)
{
unsigned i = 0;
On Jan 6, 2014, at 1:49 PM, Geoffrey Garen gga...@apple.com wrote:
auto children = elementChildren(*dummySpanAncestor);
for (auto child = children.begin(), end = children.end(); child != end;
++child) {
if (isSpanWithoutAttributesOrUnstyledStyleSpan(*child))
On Jan 6, 2014, at 1:49 PM, Geoffrey Garen gga...@apple.com wrote:
FunctionParameters::FunctionParameters(ParameterNode* firstParameter,
unsigned size)
: m_size(size)
{
unsigned i = 0;
for (ParameterNode* parameter = firstParameter; parameter; parameter =
On Jan 6, 2014, at 3:34 PM, Darin Adler da...@apple.com wrote:
On Jan 6, 2014, at 1:49 PM, Geoffrey Garen gga...@apple.com wrote:
FunctionParameters::FunctionParameters(ParameterNode* firstParameter,
unsigned size)
: m_size(size)
{
unsigned i = 0;
for (ParameterNode*
On Fri, Jan 3, 2014 at 9:28 PM, Geoffrey Garen gga...@apple.com wrote:
I strongly object to varying coding style arbitrarily based on author or
project file. That's a recipe for an unreadable polyglot codebase.
I wasn't advocating a general coding style free-for-all. I imagine there
could be
Call me an extremist, but I would be in favor of a complete ban on auto. I've
been involved in another project deciding to not use auto at all. It forces
programmers to be explicit and careful, it shows the effects of type changes
with compiler errors (exposing bugs better), and it's easy to
On Jan 4, 2014, at 4:14 PM, Alex Christensen alex.christen...@flexsim.com
wrote:
Call me an extremist, but I would be in favor of a complete ban on auto. I've
been involved in another project deciding to not use auto at all. It forces
programmers to be explicit and careful, it shows the
On Jan 4, 2014, at 9:10 AM, Andreas Kling akl...@apple.com wrote:
On Jan 4, 2014, at 4:14 PM, Alex Christensen alex.christen...@flexsim.com
wrote:
Call me an extremist, but I would be in favor of a complete ban on auto.
I've been involved in another project deciding to not use auto at
I realize that I am resisting change, and also that the WebKit community would
never agree to completely forbid a useful language feature, but I like to err
on the more explicit side of coding. It is hard to say does this make the code
cleaner more than it removes useful information? or will
Hi Alex,
On Jan 4, 2014, at 12:01 PM, Alex Christensen alex.christen...@flexsim.com
wrote:
[...] but I like to err on the more explicit side of coding. It is hard to
say does this make the code cleaner more than it removes useful
information? or will this cause problems for other
On Jan 4, 2014, at 7:14 AM, Alex Christensen alex.christen...@flexsim.com
wrote:
Call me an extremist, but I would be in favor of a complete ban on auto.
I'm not totally sold on using it almost everywhere, but auto is clearly a win
for types that are obnoxiously long to spell but rarely
On Thu, Jan 2, 2014 at 11:12 PM, Geoffrey Garen gga...@apple.com wrote:
Hi folks.
Recently, I’ve seen patches go by using the C++11 “auto” keyword. For
example, let me pick on Andreas:
http://trac.webkit.org/changeset/161143
+auto newRenderer = textNode.createTextRenderer(style);
Hi antti,
On Jan 3, 2014, at 4:12 AM, Antti Koivisto koivi...@iki.fi wrote:
If we start making rules I'd add the following:
- Use auto when the type name is already mentioned on a line:
+1
- Use auto when the type is irrelevant. This covers things like iterators
and adapter classes:
+1
I'm not Geoff, yet I'd like to offer my perspective on the specific examples
you provided.
03 янв. 2014 г., в 4:12, Antti Koivisto koivi...@iki.fi написал(а):
auto cell = toRenderTableCell(*renderer); // right
RenderTableCell cell = toRenderTableCell(*renderer); // wrong
I can't agree with
On Jan 3, 2014, at 10:11 AM, Alexey Proskuryakov a...@webkit.org wrote:
I'm not Geoff, yet I'd like to offer my perspective on the specific examples
you provided.
03 янв. 2014 г., в 4:12, Antti Koivisto koivi...@iki.fi написал(а):
auto cell = toRenderTableCell(*renderer); // right
On Fri, Jan 3, 2014 at 1:11 PM, Alexey Proskuryakov a...@webkit.org wrote:
auto sourceDescendants = descendantsOfTypeHTMLSourceElement (*this));
So do we need auto or auto here? I would know how to answer this
question immediately if it was an explicit type, but I don't know how to
answer it
On 03/01/14 19:55, Cosmin Truta wrote:
On Fri, Jan 3, 2014 at 1:11 PM, Alexey Proskuryakov a...@webkit.org
mailto:a...@webkit.org wrote:
One shouldn't need even basic familiarity with style system to see
whether code leaks, introduces refcount thrashing, or copies too much.
Using auto tends
However I also feel the harm here is debatable enough that people working
on/reviewing the code should make decisions instead of there being a project
level dictate. It is a new thing, the appropriate usage hasn't yet settled
and people should be allowed to experiment.
The experiment has
On Jan 3, 2014, at 8:28 PM, Geoffrey Garen gga...@apple.com wrote:
However I also feel the harm here is debatable enough that people working
on/reviewing the code should make decisions instead of there being a project
level dictate. It is a new thing, the appropriate usage hasn't yet settled
On Jan 3, 2014, at 10:11 AM, Alexey Proskuryakov a...@webkit.org wrote:
It might also cover smart pointer usage like your example and multiline
expansions of setSize(foo-size()).
- Use auto when type is obvious for people with basic familiarity with a
subsystem:
auto style =
On Jan 3, 2014, at 11:28 AM, Geoffrey Garen gga...@apple.com wrote:
However I also feel the harm here is debatable enough that people working
on/reviewing the code should make decisions instead of there being a project
level dictate. It is a new thing, the appropriate usage hasn't yet
On Jan 2, 2014, at 1:12 PM, Geoffrey Garen gga...@apple.com wrote:
Hi folks.
Recently, I’ve seen patches go by using the C++11 “auto” keyword. For
example, let me pick on Andreas:
http://trac.webkit.org/changeset/161143
+auto newRenderer = textNode.createTextRenderer(style);
+
On Jan 2, 2014, at 1:12 PM, Geoffrey Garen gga...@apple.com wrote:
Hi folks.
Recently, I’ve seen patches go by using the C++11 “auto” keyword. For
example, let me pick on Andreas:
http://trac.webkit.org/changeset/161143
+auto newRenderer = textNode.createTextRenderer(style);
+
02 янв. 2014 г., в 13:12, Geoffrey Garen gga...@apple.com написал(а):
I think an appropriate style guideline for “auto” would say something like:
- Use “auto to declare a disgusting templated iterator type in a loop
- Use “auto… - to define a template-dependent return type in a class
On Thu, 2014-01-02 at 13:12 -0800, Geoffrey Garen wrote:
I think an appropriate style guideline for “auto” would say something like:
- Use “auto to declare a disgusting templated iterator type in a loop
- Use “auto… - to define a template-dependent return type in a class
template
- In
On Jan 2, 2014, at 1:40 PM, Dan Bernstein m...@apple.com wrote:
On Jan 2, 2014, at 1:12 PM, Geoffrey Garen gga...@apple.com wrote:
Hi folks.
Recently, I’ve seen patches go by using the C++11 “auto” keyword. For
example, let me pick on Andreas:
On Jan 2, 2014, at 1:54 PM, Filip Pizlo fpi...@apple.com wrote:
I think the goal should be that if you do introduce a temporary variable for
some reason, then being explicit about its type is better. Consider that in
your second example, there might be 200 lines of code between the call to
I found
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
very persuasive in my thinking about when to use auto.
-Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Jan 2, 2014, at 1:59 PM, Brent Fulgham bfulg...@apple.com wrote:
Hi,
On Jan 2, 2014, at 1:12 PM, Geoffrey Garen gga...@apple.com wrote:
+auto newRenderer = textNode.createTextRenderer(style);
+ASSERT(newRenderer);
….
+parentRenderer-addChild(newRenderer.leakPtr(),
I think this use of “auto” is net harmful.
I disagree. I think the use of auto is an improvement, because it makes it
less likely that we have something like the following:
int wrong = something.get64BitInt(); // potential truncation
This argument is a red herring for two reasons:
(1)
We tend to avoid local write-once-read-once local variables, i.e. we tend to
prefer
{
setSize(optimalSize());
}
to
{
CGSize newSize = optimalSize();
setSize(newSize);
}
But the up- and down-sides of this are the same as those of using auto.
I think I basically agree
What do you think about these examples?
auto failureCallback = [promiseWrapper]() mutable {
promiseWrapper.reject(nullptr);
};
Here I think auto is good because the type is disgusting to write out by hand,
and because the type is clearly visible on the right hand side of
Hi Adam,
On Jan 2, 2014, at 2:08 PM, Adam Roben aro...@webkit.org wrote:
I found
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
very persuasive in my thinking about when to use auto.
I think this does a much better job of explaining the benefits of ‘auto’
I think that this article is one of many great examples of arguments in favor
of less explicit typing. These lines of reasoning are often used by proponents
of both dynamic languages (like Ruby) and type-inferred languages (like ML or
Haskell). C++'s auto is almost exactly like what ML and
Hi Filip,
Coming back to your earlier example:
auto newSize = optimalSize();
vs:
CGSize newSize = optimalSize();
If I understand your argument, you feel that the explicit CGSize declaration
helps the reader because it makes the return value of optimalSize() explicit.
However, that
One interesting point in this article, which I tend to agree with, is that it
seems generally appropriate to use “auto” in any line of code that already
conveys type. For example:
(1) Lambda, as pointed out by Alexey:
auto failureCallback = [promiseWrapper]() mutable {
On Jan 2, 2014, at 2:55 PM, Brent Fulgham bfulg...@apple.com wrote:
Hi Filip,
Coming back to your earlier example:
auto newSize = optimalSize();
vs:
CGSize newSize = optimalSize();
If I understand your argument, you feel that the explicit CGSize declaration
helps the reader
On Thu, Jan 02, 2014 at 01:12:46PM -0800, Geoffrey Garen wrote:
Hi folks.
Recently, I’ve seen patches go by using the C++11 “auto” keyword. For
example, let me pick on Andreas:
http://trac.webkit.org/changeset/161143
+auto newRenderer = textNode.createTextRenderer(style);
+
On Thu, Jan 2, 2014 at 4:12 PM, Geoffrey Garen gga...@apple.com wrote:
I think an appropriate style guideline for “auto” would say something like:
- Use “auto to declare a disgusting templated iterator type in a loop
- Use “auto… - to define a template-dependent return type in a class
On Jan 2, 2014, at 2:48 PM, Filip Pizlo fpi...@apple.com wrote:
I think that this article is one of many great examples of arguments in favor
of less explicit typing. These lines of reasoning are often used by
proponents of both dynamic languages (like Ruby) and type-inferred languages
44 matches
Mail list logo
