Files.app: Fix closure error which will raised by the updated compiler.

Files.app: Fix closure error which will raised by the updated compiler.

BUG=467807
TEST=bump compiler version and compile all targets under ui/file_manager.

Committed: https://crrev.com/7d6166f4461ed1c2a31ae6d3fd5a941a5625203c
Cr-Commit-Position: refs/heads/master@{#321299}

[fukino, 2015-03-17 06:25:42]

fukino@chromium.org changed reviewers:
+ yoshiki@chromium.org

[fukino, 2015-03-17 06:25:43]

Could you take a look?

It should be better to have specific type for fake entries. I'll do it in a
separate CL.

[yoshiki, 2015-03-17 08:51:07]

General Comment: We shouldn't degenerate FakeEntry into Object. We can't get any
advantage of Closure Compiler from Object.


I think, it's good to treat a FakeEntry as an Entry. Isn't it possible?

[fukino, 2015-03-17 10:44:00]

On 2015/03/17 08:51:07, yoshiki wrote:
> General Comment: We shouldn't degenerate FakeEntry into Object. We can't get
any
> advantage of Closure Compiler from Object.
> 
> 
> I think, it's good to treat a FakeEntry as an Entry. Isn't it possible?

We can not safely pass a FakeEntry to a function which takes Entry, so I think
it's better to define FakeEntry type which is independent to Entry.

[yoshiki, 2015-03-17 11:18:40]

On 2015/03/17 10:44:00, fukino wrote:
> On 2015/03/17 08:51:07, yoshiki wrote:
> > General Comment: We shouldn't degenerate FakeEntry into Object. We can't get
> any
> > advantage of Closure Compiler from Object.
> > 
> > 
> > I think, it's good to treat a FakeEntry as an Entry. Isn't it possible?
> 
> We can not safely pass a FakeEntry to a function which takes Entry, so I think
> it's better to define FakeEntry type which is independent to Entry.

SGTM. Could you define and use FakeEntry instead of generic Object? Thanks.

[yoshiki, 2015-03-17 11:18:42]

On 2015/03/17 10:44:00, fukino wrote:
> On 2015/03/17 08:51:07, yoshiki wrote:
> > General Comment: We shouldn't degenerate FakeEntry into Object. We can't get
> any
> > advantage of Closure Compiler from Object.
> > 
> > 
> > I think, it's good to treat a FakeEntry as an Entry. Isn't it possible?
> 
> We can not safely pass a FakeEntry to a function which takes Entry, so I think
> it's better to define FakeEntry type which is independent to Entry.

SGTM. Could you define and use FakeEntry instead of generic Object? Thanks.

[fukino, 2015-03-18 11:00:51]

On 2015/03/17 11:18:42, yoshiki wrote:
> On 2015/03/17 10:44:00, fukino wrote:
> > On 2015/03/17 08:51:07, yoshiki wrote:
> > > General Comment: We shouldn't degenerate FakeEntry into Object. We can't
get
> > any
> > > advantage of Closure Compiler from Object.
> > > 
> > > 
> > > I think, it's good to treat a FakeEntry as an Entry. Isn't it possible?
> > 
> > We can not safely pass a FakeEntry to a function which takes Entry, so I
think
> > it's better to define FakeEntry type which is independent to Entry.
> 
> SGTM. Could you define and use FakeEntry instead of generic Object? Thanks.

Thanks! I defined FakeEntry record type and use it instead of Object type.
Could you take another look?

[yoshiki, 2015-03-19 04:10:15]

On 2015/03/18 11:00:51, fukino wrote:
> On 2015/03/17 11:18:42, yoshiki wrote:
> > On 2015/03/17 10:44:00, fukino wrote:
> > > On 2015/03/17 08:51:07, yoshiki wrote:
> > > > General Comment: We shouldn't degenerate FakeEntry into Object. We can't
> get
> > > any
> > > > advantage of Closure Compiler from Object.
> > > > 
> > > > 
> > > > I think, it's good to treat a FakeEntry as an Entry. Isn't it possible?
> > > 
> > > We can not safely pass a FakeEntry to a function which takes Entry, so I
> think
> > > it's better to define FakeEntry type which is independent to Entry.
> > 
> > SGTM. Could you define and use FakeEntry instead of generic Object? Thanks.
> 
> Thanks! I defined FakeEntry record type and use it instead of Object type.
> Could you take another look?

LGTM. Thank you for addressing my comments!

[fukino, 2015-03-19 04:37:25]

On 2015/03/19 04:10:15, yoshiki wrote:
> On 2015/03/18 11:00:51, fukino wrote:
> > On 2015/03/17 11:18:42, yoshiki wrote:
> > > On 2015/03/17 10:44:00, fukino wrote:
> > > > On 2015/03/17 08:51:07, yoshiki wrote:
> > > > > General Comment: We shouldn't degenerate FakeEntry into Object. We
can't
> > get
> > > > any
> > > > > advantage of Closure Compiler from Object.
> > > > > 
> > > > > 
> > > > > I think, it's good to treat a FakeEntry as an Entry. Isn't it
possible?
> > > > 
> > > > We can not safely pass a FakeEntry to a function which takes Entry, so I
> > think
> > > > it's better to define FakeEntry type which is independent to Entry.
> > > 
> > > SGTM. Could you define and use FakeEntry instead of generic Object?
Thanks.
> > 
> > Thanks! I defined FakeEntry record type and use it instead of Object type.
> > Could you take another look?
> 
> LGTM. Thank you for addressing my comments!

Thank you!

[fukino, 2015-03-19 04:37:25]

On 2015/03/19 04:10:15, yoshiki wrote:
> On 2015/03/18 11:00:51, fukino wrote:
> > On 2015/03/17 11:18:42, yoshiki wrote:
> > > On 2015/03/17 10:44:00, fukino wrote:
> > > > On 2015/03/17 08:51:07, yoshiki wrote:
> > > > > General Comment: We shouldn't degenerate FakeEntry into Object. We
can't
> > get
> > > > any
> > > > > advantage of Closure Compiler from Object.
> > > > > 
> > > > > 
> > > > > I think, it's good to treat a FakeEntry as an Entry. Isn't it
possible?
> > > > 
> > > > We can not safely pass a FakeEntry to a function which takes Entry, so I
> > think
> > > > it's better to define FakeEntry type which is independent to Entry.
> > > 
> > > SGTM. Could you define and use FakeEntry instead of generic Object?
Thanks.
> > 
> > Thanks! I defined FakeEntry record type and use it instead of Object type.
> > Could you take another look?
> 
> LGTM. Thank you for addressing my comments!

Thank you!

[fukino, 2015-03-19 04:37:36]

The CQ bit was checked by fukino@chromium.org

[commit-bot: I haz the power, 2015-03-19 04:38:02]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1010163002/20001

[commit-bot: I haz the power, 2015-03-19 05:08:37]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-19 05:09:09]

Patchset 2 (id:??) landed as
https://crrev.com/7d6166f4461ed1c2a31ae6d3fd5a941a5625203c
Cr-Commit-Position: refs/heads/master@{#321299}