ConstantReader#peek

[matanlurey]

In contrast with read, peek should return a null value instead of throwing an exception if a field is not found. This allows a more graceful way of checking for this first non-null value, for example:

findTokenField(DartObject o) {
  final reader = new ConstantReader(o);
  final token = o.peek('token') ?? o.peek('_token');
}

Other options:

1. Add an Function<Object> orElse parameter to read.
2. Add an explicit way to read/check many parameters, i.e.

final token = o.read('token', '_token'); 

// or

final token = o.readFirst(['token', '_token']);

[matanlurey]

3rd-option: Add has:

if (o.has('token')) {
  // ...
} else if (o.has('_token')) {
  // ...
}

[matanlurey]

/cc @alorenzen @natebosch for thoughts.

[natebosch]

I like the way your first proposal composes, but the name leaves something to be desired.

I think we should add both has and peek as proposed - but if anyone can think of a different name for peek before we implement it that would be good.

[zoechi]

What about o.read('token', orElse: (e) => null) like it's done in other SDK APIs?

[natebosch]

Consistency with existing APIs is a very strong argument.
I think, though, that most of those were written before ?? existed and I don't think orElse composes as nicely... Compare:

var x = reader.read('foo', orElse: () => reader.read('bar', orElse: () => 'default'));

with

var x = reader.peek('foo') ?? reader.peek('bar') ?? 'default';

I can't think of any places where orElse is easier to read that peek + ?? - but if we find such a place we can definitely revisit this.

[zoechi]

I see. Thanks for explaining the reasoning.