[dart-misc] Null aware map lookup

[Lasse Damgaard]

The new null aware operators are awesome. One thing I'm really missing
however is null aware map lookup.
In other words I want this to be true instead of a compile error:

Map nullMap;
expect(nullMap?['foobar'], isNull);


Are there any plans to add this?

Alternatively, instead of supporting null aware access for overloaded
operators Map should just define add and get methods.
I've also been missing that in other situations such as this completely
nonsense example:


final someMap = {'foo':1, 'bar':2, 'baz':3};
final values = [1,2].map(someMap.get);


Lasse

['Lasse R.H. Nielsen' via Dart Misc]

This is special case of null-aware operators extending to operators, not
just methods.
You also can't do:
maybeNull ?+ 42
maybeNull?[42]
maybeNull?(42, 37) // but you can do maybeNull?.call(42, 37) instead

There are some syntactic problems with allowing this because the ? might
look like part of the conditional operator (?:). If you write:
a?(b)?-4:42
it's not clear how to parse it. It would still be "nice-to-have" if we can
find a way to avoid the ambiguity.
I'm willing to write x?.[42] for the null-aware index operator.

/L

Post by Lasse Damgaard
The new null aware operators are awesome. One thing I'm really missing
however is null aware map lookup.
Map nullMap;
expect(nullMap?['foobar'], isNull);
Are there any plans to add this?
Alternatively, instead of supporting null aware access for overloaded
operators Map should just define add and get methods.
I've also been missing that in other situations such as this completely
final someMap = {'foo':1, 'bar':2, 'baz':3};
final values = [1,2].map(someMap.get);
Lasse
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Lasse Damgaard]

Yes. I should have mentioned that I bring up the Map index case because it
occurs all the time (for me) when parsing JSON, not because it's special in
itself.

maybeNull.?[42] would be fine also.

However, at the risk of derailing my own question I would actually just
prefer collection classes that use operator overloading to also provide
methods that do the same because overloaded operators don't play well with
a functional style given the current syntax. So for instance List should
also define an 'itemAt' alternative to the index operator etc...

On Thursday, September 17, 2015 at 9:41:21 AM UTC+2, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc
This is special case of null-aware operators extending to operators, not
just methods.
maybeNull ?+ 42
maybeNull?[42]
maybeNull?(42, 37) // but you can do maybeNull?.call(42, 37) instead
There are some syntactic problems with allowing this because the ? might
a?(b)?-4:42
it's not clear how to parse it. It would still be "nice-to-have" if we can
find a way to avoid the ambiguity.
I'm willing to write x?.[42] for the null-aware index operator.
/L

Post by Lasse Damgaard
The new null aware operators are awesome. One thing I'm really missing
however is null aware map lookup.
Map nullMap;
expect(nullMap?['foobar'], isNull);
Are there any plans to add this?
Alternatively, instead of supporting null aware access for overloaded
operators Map should just define add and get methods.
I've also been missing that in other situations such as this completely
final someMap = {'foo':1, 'bar':2, 'baz':3};
final values = [1,2].map(someMap.get);
Lasse
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

['Andreas Kirsch' via Dart Misc]

+1 for that. Iterable has elementAt.

Post by Lasse Damgaard
Yes. I should have mentioned that I bring up the Map index case because it
occurs all the time (for me) when parsing JSON, not because it's special in
itself.
maybeNull.?[42] would be fine also.
However, at the risk of derailing my own question I would actually just
prefer collection classes that use operator overloading to also provide
methods that do the same because overloaded operators don't play well with
a functional style given the current syntax. So for instance List should
also define an 'itemAt' alternative to the index operator etc...
On Thursday, September 17, 2015 at 9:41:21 AM UTC+2, Lasse Reichstein

Post by 'Lasse R.H. Nielsen' via Dart Misc
This is special case of null-aware operators extending to operators, not
just methods.
maybeNull ?+ 42
maybeNull?[42]
maybeNull?(42, 37) // but you can do maybeNull?.call(42, 37) instead
There are some syntactic problems with allowing this because the ? might
a?(b)?-4:42
it's not clear how to parse it. It would still be "nice-to-have" if we
can find a way to avoid the ambiguity.
I'm willing to write x?.[42] for the null-aware index operator.
/L

The new null aware operators are awesome. One thing I'm really missing

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Lasse Damgaard
however is null aware map lookup.
Map nullMap;
expect(nullMap?['foobar'], isNull);
Are there any plans to add this?
Alternatively, instead of supporting null aware access for overloaded
operators Map should just define add and get methods.
I've also been missing that in other situations such as this completely
final someMap = {'foo':1, 'bar':2, 'baz':3};
final values = [1,2].map(someMap.get);
Lasse

--

Post by Lasse Damgaard
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

'Faith without judgement merely degrades the spirit divine'

Post by 'Lasse R.H. Nielsen' via Dart Misc
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Jan Mostert]

+1

On Thu, 17 Sep 2015 at 10:03 'Andreas Kirsch' via Dart Misc <

Post by 'Andreas Kirsch' via Dart Misc
+1 for that. Iterable has elementAt.

Post by Lasse Damgaard
Yes. I should have mentioned that I bring up the Map index case because
it occurs all the time (for me) when parsing JSON, not because it's special
in itself.
maybeNull.?[42] would be fine also.
However, at the risk of derailing my own question I would actually just
prefer collection classes that use operator overloading to also provide
methods that do the same because overloaded operators don't play well with
a functional style given the current syntax. So for instance List should
also define an 'itemAt' alternative to the index operator etc...
On Thursday, September 17, 2015 at 9:41:21 AM UTC+2, Lasse Reichstein

Post by 'Lasse R.H. Nielsen' via Dart Misc
This is special case of null-aware operators extending to operators, not
just methods.
maybeNull ?+ 42
maybeNull?[42]
maybeNull?(42, 37) // but you can do maybeNull?.call(42, 37) instead
There are some syntactic problems with allowing this because the ? might
a?(b)?-4:42
it's not clear how to parse it. It would still be "nice-to-have" if we
can find a way to avoid the ambiguity.
I'm willing to write x?.[42] for the null-aware index operator.
/L

The new null aware operators are awesome. One thing I'm really missing

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Lasse Damgaard
however is null aware map lookup.
Map nullMap;
expect(nullMap?['foobar'], isNull);
Are there any plans to add this?
Alternatively, instead of supporting null aware access for overloaded
operators Map should just define add and get methods.
I've also been missing that in other situations such as this completely
final someMap = {'foo':1, 'bar':2, 'baz':3};
final values = [1,2].map(someMap.get);
Lasse

--

Post by Lasse Damgaard
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

'Faith without judgement merely degrades the spirit divine'

Post by 'Lasse R.H. Nielsen' via Dart Misc
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Lasse Damgaard]

Post by 'Andreas Kirsch' via Dart Misc
+1 for that. Iterable has elementAt.

Doh! Of all the available examples I picked the wrong one :-)

['Lasse R.H. Nielsen' via Dart Misc]

Post by Lasse Damgaard
Yes. I should have mentioned that I bring up the Map index case because it
occurs all the time (for me) when parsing JSON, not because it's special in
itself.
maybeNull.?[42] would be fine also.
However, at the risk of derailing my own question I would actually just
prefer collection classes that use operator overloading to also provide
methods that do the same because overloaded operators don't play well with
a functional style given the current syntax. So for instance List should
also define an 'itemAt' alternative to the index operator etc...

That would suggest moving away from having special "operator+"
declarations, and just make "a + b" always be equivalent to "a.plus(b)".
For example, that's what Python does with its __-prefixed functions.

It would also avoid needing special syntax for tearing off operators, you
can just tear it off by name instead.

This would currently be a breaking change since there might exist classes
with both "operator+" and "plus" members (even if it would be a little
embarrassing :P).


Exactly the index operator actually does exist on List, it's "elementAt",
but the rest do not have corresponding methods.

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Lasse Damgaard]

On Thursday, September 17, 2015 at 10:35:11 AM UTC+2, Lasse Reichstein

Post by 'Lasse R.H. Nielsen' via Dart Misc
That would suggest moving away from having special "operator+"
declarations, and just make "a + b" always be equivalent to "a.plus(b)".
For example, that's what Python does with its __-prefixed functions.
It would also avoid needing special syntax for tearing off operators, you
can just tear it off by name instead.
This would currently be a breaking change since there might exist classes
with both "operator+" and "plus" members (even if it would be a little
embarrassing :P).

Yes something like that but perhaps without the semi magic and hidden way
this works in Python. What if you could just combine a method name and
operator in function declarations?
Something like:

Object operator [] get(Object key);
bool operator == equals(Object other);


I suppose this could be made nonbreaking by just making the method name
optional although I would be in favor of enforcing the method name, at
least in the long run.

The index operator is obviously a problem here because you want to do both:

dynamic operator [] get(key);
void operator [] put(key, value);


Not sure how/if that could be solved.

In any case it seems that an advantage of this approach would be that for
some operators such as index the corresponding method name is not totally
obvious and might be context specific. So the ability to write it out in
combination with the operator is more clear than __getitem__ and
__setitem__ just being hardwired to [] at the language level.

Thoughts?

Lasse

[Günter Zöchbauer]

Post by Lasse Damgaard
On Thursday, September 17, 2015 at 10:35:11 AM UTC+2, Lasse Reichstein

Post by 'Lasse R.H. Nielsen' via Dart Misc
That would suggest moving away from having special "operator+"
declarations, and just make "a + b" always be equivalent to "a.plus(b)".
For example, that's what Python does with its __-prefixed functions.
It would also avoid needing special syntax for tearing off operators, you
can just tear it off by name instead.
This would currently be a breaking change since there might exist classes
with both "operator+" and "plus" members (even if it would be a little
embarrassing :P).

Yes something like that but perhaps without the semi magic and hidden way
this works in Python. What if you could just combine a method name and
operator in function declarations?
Object operator [] get(Object key);
bool operator == equals(Object other);
I suppose this could be made nonbreaking by just making the method name
optional although I would be in favor of enforcing the method name, at
least in the long run.
Object operator [] get(Object key);
void operator [] put(Object key, Object value);

Not sure what problem you're referring here.
I guess this should be:
void operator []= put(Object key, Object value);

Post by Lasse Damgaard
Not sure how/if that could be solved.
In any case it seems that an advantage of this approach would be that for
some operators such as index the corresponding method name is not totally
obvious and might be context specific. So the ability to write it out in
combination with the operator is more clear than __getitem__ and
__setitem__ just being hardwired to [] at the language level.
Thoughts?
Lasse

[Lasse Damgaard]

Post by Günter Zöchbauer
Not sure what problem you're referring here.
void operator []= put(Object key, Object value);

You're right, there's no issue. For once I'm happy to be wrong :-)