Primitive streams and optional (original) (raw)
Remi Forax forax at univ-mlv.fr
Wed Dec 5 05:19:24 PST 2012
- Previous message: Primitive streams and optional
- Next message: Primitive streams and optional
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/05/2012 01:56 PM, Doug Lea wrote:
On 12/05/12 07:42, Remi Forax wrote:
This experience among others led to the non-nulls policy in j.u.c.
If we can go back in time and disallow null for all collections, we will live in a better world, but that not the case. If we could go back in time and disallow null for all streams, we will live in a better world. Oh, wait! We don't have to go back in time! We can just make a better world!
That was the first idea, but there is not a lot of streams that are not baked by a collection. If we don't tolerate null in stream, we create an island with nice rules inside the island and a hell for people that want to go to that island or go out of that island. And we don't want a million of devs to become number 6, right ? [1].
I'm pretty sure that because j.u.c collections use null to tag entry that should be removed and because the VM aggressively optimizes value that was never null before, code that triggers de-optimization the first time you remove an element from a concurrent collection should exist. I'm pretty sure that all such cases are OK because they trigger different branches that would somehow need encoding anyway. So branching on null vs branching on something else is a wash. (Although there might be a case here and there where different encodings might win because they currently disable triggerings of agressive-null mechanics that would otherwise be enabled along branches. -Doug
Rémi
[1] https://en.wikipedia.org/wiki/The_Prisoner
- Previous message: Primitive streams and optional
- Next message: Primitive streams and optional
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-experts mailing list