Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(128)

Issue 1129373003: New return value syntax for HashTable and HashMap nested types

Created:
5 years, 7 months ago by Mikhail
Modified:
5 years, 7 months ago
CC:
aandrey+blink_chromium.org, blink-reviews, blink-reviews-wtf_chromium.org
Base URL:
https://chromium.googlesource.com/chromium/blink.git@master
Target Ref:
refs/heads/master
Project:
blink
Visibility:
Public.

Description

New return value syntax for HashTable and HashMap nested types Add some sugar to improve readability.

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+20 lines, -28 lines) Patch
M Source/wtf/HashMap.h View 5 chunks +14 lines, -22 lines 0 comments Download
M Source/wtf/HashTable.h View 6 chunks +6 lines, -6 lines 0 comments Download

Messages

Total messages: 6 (1 generated)
Mikhail
PTAL
5 years, 7 months ago (2015-05-08 11:24:35 UTC) #2
jochen (gone - plz use gerrit)
any particular reason to change this?
5 years, 7 months ago (2015-05-08 17:22:24 UTC) #3
Mikhail
On 2015/05/08 17:22:24, jochen (traveling) wrote: > any particular reason to change this? as I ...
5 years, 7 months ago (2015-05-11 08:06:58 UTC) #4
jochen (gone - plz use gerrit)
On 2015/05/11 at 08:06:58, mikhail.pozdnyakov wrote: > On 2015/05/08 17:22:24, jochen (traveling) wrote: > > ...
5 years, 7 months ago (2015-05-11 23:31:12 UTC) #5
Mikhail
5 years, 7 months ago (2015-05-12 11:08:14 UTC) #6
On 2015/05/11 23:31:12, jochen (traveling) wrote:
> On 2015/05/11 at 08:06:58, mikhail.pozdnyakov wrote:
> > On 2015/05/08 17:22:24, jochen (traveling) wrote:
> > > any particular reason to change this?
> > 
> > as I wrote this is just a syntax sugar :) however that makes method's
> definition significantly more compact and the code is easier to comprehend.
> 
> I don't think that we should do changes like this without an actual need,
sorry.

No problem, I understand your point for being reluctant to non-functional
changes, however in this particular case I do not see the alternative -- we will
hardly ever re-write the whole HashTable/HashMap classes so that the new
semantics would come naturally.. at the same time this new semantics simplifies
reading code quite a lot. I'd say it was invented exactly for such cases like
"inline typename HashTable<Key, Value, Extractor, HashFunctions, Traits, KeyT
raits, Allocator>::FullLookupType HashTable<Key, Value, Extractor, HashFunctions
, Traits, KeyTraits, .. (and you've to scroll to see the method name)"

Powered by Google App Engine
This is Rietveld 408576698