[dart-misc] Resolving const objects by dynamic parameters

[Nick Reid]

What you're struggling with is an age old programming problem with probably
no great solution (I think the best one is steering clear of it with
polymorphism and design forethought), but anyway...

Using switch is a preferred solution. I'd recommend something more like:
bool argsMatch(List a, List b) {

}

['Erik Ernst' via Dart Misc]

What you are really asking for, Philipp, is the ability to express
composite values in Dart, that is, immutable entities with no identity. The
lack of identity can be achieved in several ways, and canonicalization is
one of them, but it could also be done by ensuring that values are always
compared structurally (with pointer equality as a shortcut, whenever it
occurs).

We do have support for composite values in Dart with `const` expressions,
but not for expressions involving runtime values, and it's not going to be
a trivial exercise to get good support for them.

So one relevant question for now would be whether you could make do with
the compile-time expressions---would it be acceptable for you to make a
centralized decision about which composite values to support?

After all, you are dealing with a specific and (very ;-) finite set of
values in the concrete `switch` example, and "taking the union" of all such
`swich` statements (and a similar constructs like `.. == const ["foo", 1]`)
would give you the values you need to know about. With such a global set
you could write the function you're asking for (taking `["foo", 1]` and
returning `const ["foo", 1]`, taking `["baz", 42]` and throwing, or
whatever). That might be a usable work-around for now, and then you could
switch on `const this-and-that` and keep the work-around encapsulated in
that single function.

Post by Nick Reid
What you're struggling with is an age old programming problem with
probably no great solution (I think the best one is steering clear of it
with polymorphism and design forethought), but anyway...
bool argsMatch(List a, List b) {
}
--
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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

[Philipp S]

Post by 'Erik Ernst' via Dart Misc
So one relevant question for now would be whether you could make do with
the compile-time expressions---would it be acceptable for you to make a
centralized decision about which composite values to support?

Yes, absolutely – If I wanted dynamic composite values, I'd just build up a
cache at runtime (as explained here:
https://www.dartlang.org/dart-tips/dart-tips-ep-11.html)

After all, you are dealing with a specific and (very ;-) finite set of

Post by 'Erik Ernst' via Dart Misc
values in the concrete `switch` example, and "taking the union" of all such
`swich` statements (and a similar constructs like `.. == const ["foo", 1]`)
would give you the values you need to know about. With such a global set
you could write the function you're asking for (taking `["foo", 1]` and
returning `const ["foo", 1]`, taking `["baz", 42]` and throwing, or
whatever). That might be a usable work-around for now, and then you could
switch on `const this-and-that` and keep the work-around encapsulated in
that single function.

I implemented the function like that for now, defining and looking up my
values in a nested map. const {List: const {"foo": const {1: const ["foo",
1], 2: ...}}}
I'm not really happy with it, because I feel like it's too easy to make a
copy/paste error there. I may iterate on the idea to auto-generate that
function and keep this thread updated.

But for now, thanks again!
Philipp

[Nick Reid]

Out of curiosity, why are you interested in using const values this way?
Do you they give you some kind of performance gain over runtime?

[Philipp S]

Post by Nick Reid
Out of curiosity, why are you interested in using const values this way?
Do you they give you some kind of performance gain over runtime?

No, its not about performance, its about readability. I probably spend more
time reflecting on how I phrase an algorithm, than on inventing it. And in
this case (executing exactly one of n equally prioritized branches,
depending on a uniform comparison condition) the language construct that
describes my intent most accurately is `switch`.
And yes, I've been told that that's a pure waste of time, but in the past
it worked out for me pretty well whenever I had to change that code a month
later – and besides, it's a private project, so there's no deadline :-)

[Nick Reid]

Ahh, fair enough. I'm guilty of the same thing.

So then if constness has no objective advantage, why not use a runtime assembled lookup system? To me that would have the added advantage of reducing visual noise since there wouldn't be consts floating around everywhere.

Out of curiosity, why are you interested in using const values this way? Do you they give you some kind of performance gain over runtime?

No, its not about performance, its about readability. I probably spend more time reflecting on how I phrase an algorithm, than on inventing it. And in this case (executing exactly one of n equally prioritized branches, depending on a uniform comparison condition) the language construct that describes my intent most accurately is `switch`.
And yes, I've been told that that's a pure waste of time, but in the past it worked out for me pretty well whenever I had to change that code a month later – and besides, it's a private project, so there's no deadline :-)
--
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
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.