The Optional javadoc refers to a Holder class will this be released as
well or was this an unintentional leak of things to come?
-- JR
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
1. Serialization. You're right. I keep forgetting that we don't make any guarantees about portability of serialized forms across versions, so serialization is actually a lot easier than it was back when we were actually shooting for that. Would anyone be able to pull together a list of *all* the types that make sense to be serializable and file an omnibus feature request?
2. I'm not sure it was that important for us to implement ImmutableSortedSet at all; or if we just did it because, hey, it's immutable. We could back that out. If we don't, then perhaps DiscreteDomain will have to get the "add this distance to this point" method you describe, because asList() is too scary otherwise. At one point we were hoping DiscreteDomain would support "partial" domains like "prime integers" or "Wednesdays", and under that model the method you describe didn't necessarily make sense, but we had to back away from that and settle for a DiscreteDomain only representing the entire type that it's parameterized on.
5. Whoops, I'm sure we mean to let you create your own DiscreteDomains. Note that it may not work for what you want (a subset of the possible values of a type).
Well, the domain *would* cover all instances of my class that can be constructed (trying to make a FiscalYear with a value less than 1977 throws an exception) so I wouldn't think it'd be considered a subset even though it doesn't cover all years or integers. Plus, the way I'd be using it is very simple... just relatively small closed ranges.
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
> - get(T defaultValue) reads better as getOrElse(T defaultValue)
reads wrong, too. you're not getting the defaultValue. you're getting the provided value and only the default value if the provided value is null.
x.get(y) reads totally confusing when under normal circumstances you'd get the value contained by x, not y.
x.getOrElse(y) is a few more characters, but at least it's clear and transparent about what it really does.
> Maarten, I'm a little confused – I was proposing getOrElse(T) instead of get(T) and you are +1 ?
Looks like I read your "as" as a "than" (blame my native language). Then for the reasons below, I am +1, yes :-)
> --
> cheers,
> - jed.
Kevin, it is fantastic to finally have a somewhat standard Option class in a common library, but almost every implementation I have seen follows the scala/haskell idiom of Option/Some/None. Is there any chance of following this convention rather than inventing a new mostly similar one?I am not expecting all of the functionality, just the basic naming, use Option<T> with Some and None concrete implementations.
Minor points:- it can implement Supplier<T>
- get(T defaultValue) reads better as getOrElse(T defaultValue)
- please (please) add Option<S> transform(Function<T, S> f)- or implement Iterable<T> so we can wire that up ourselves
> Kevin, it is fantastic to finally have a somewhat standard Option class in a common library, but almost every implementation I have seen follows the scala/haskell idiom of Option/Some/None. Is there any chance of following this convention rather than inventing a new mostly similar one?
>
> http://www.scala-lang.org/api/current/scala/Option.html
>
> I am not expecting all of the functionality, just the basic naming, use Option<T> with Some and None concrete implementations.
You're suggesting renaming Optional to Option? I'm actually happy to see different names between Scala and Guava, it'll make it clearer in mixed code whose option it is.
>
> Minor points:
> - it can implement Supplier<T>
> - get(T defaultValue) reads better as getOrElse(T defaultValue)
> - please (please) add Option<S> transform(Function<T, S> f)
What about naming this map, to be consistent with Scala? I'm guessing transform() is the common name used throughout Guava?
> - or implement Iterable<T> so we can wire that up ourselves
You would want this in addition to transform(), if you don't care about transform()'s result?
Regards,
Blair
Am 27.04.2011 07:44, schrieb Jed Wesley-Smith:
> Kevin, it is fantastic to finally have a somewhat standard Option class in a
> common library, but almost every implementation I have seen follows the
> scala/haskell idiom of Option/Some/None. Is there any chance of following
> this convention rather than inventing a new mostly similar one?
>
> http://www.scala-lang.org/api/current/scala/Option.html
>
> I am not expecting all of the functionality, just the basic naming, use
> Option<T> with Some and None concrete implementations.
I like Optional<T> more than Option<T>. It reads more naturally like
"optional value of T". Also a class Option might be misunderstood to
designate configuration options, or it produces name clashes with
option-handling classes (for example, I have an annotation @Option that
is used for annotating fields which store configuration option values).
Greetings, Philipp
Er, "there may or may not be a thing there" is exactly what Optional is for!
Kevin, it is fantastic to finally have a somewhat standard Option class in a common library, but almost every implementation I have seen follows the scala/haskell idiom of Option/Some/None. Is there any chance of following this convention rather than inventing a new mostly similar one?I am not expecting all of the functionality, just the basic naming, use Option<T> with Some and None concrete implementations.I think it's better not to raise the expectations of Scala and Haskell devotees by using such suggestive names.
Minor points:- it can implement Supplier<T>But should it? Anyone treating it as a supplier is bound to be disappointed by the way it can throw IllegalStateException.
- get(T defaultValue) reads better as getOrElse(T defaultValue)Yes, or opt.getWithDefault(defVal) or opt.getDefaultingTo(defVal).
I agree, but I think that's a problem, not a benefit. Option to me implies that there is a fixed choice; you get A or B. Optional is more vague. To me it says maybe there may or may not be a thing there, possibly.
I think there's a general bias in favor of using nouns instead of adjectives for objects.
I also think there should be a small bias in favor of what other languages are already doing; Scala, OCaml/F# use Option. Is there a reason to think those communities regret the choice and would rather have gone with Optional?
- please (please) add Option<S> transform(Function<T, S> f)
- or implement Iterable<T> so we can wire that up ourselves
I hear you. We felt it doesn't fit nicely on the Option class itself,
On Wed, Apr 27, 2011 at 9:37 AM, Colin Decker <cgde...@gmail.com> wrote:Er, "there may or may not be a thing there" is exactly what Optional is for!I'm trying to argue something that's very slightly different. To me, it feels something like:Optional: it may or may not be there.Option: it is or is not there.
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
Ideally, equals for Maybe<T> would return Maybe<Boolean> but it's not
possible to do that in Java,
For Optional<T>, it makes sense for equals to return false when
applied to two "nothing" values.
As for the rest of the class, feel free to adopt any parts you feel
like. Assume the same license as Guava (Apache 2.0?).
--Nat.
> --
> guava-...@googlegroups.com
> Project site: http://guava-libraries.googlecode.com
> This group: http://groups.google.com/group/guava-discuss
>
> This list is for general discussion.
> To report an issue: http://code.google.com/p/guava-libraries/issues/entry
> To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
>
I like the name "otherwise" and the overload for otherwise(Maybe<T>), I like the integration with Predicate and Function. But the fact that unknown() creates always a new instance not equal to any other unknown() is strange and precludes the use as a null substitute in maps not allowing null. The public constructor may be a problem, too.
Otherwise is the name I used for getOrElse in my Maybe<T> class,
While I'm a Haskell devotee, and I love Haskell's Maybe, I'm going to defend both Kevin's implementation and his management style. Pardon my rant.
- There is a design pattern, common in Java, in which a "null" value for a variable exclusively represents "not here." Optional, as it is written, is perfectly designed to stand in for this pattern, while being safer and more difficult to screw up. This is a common pattern in Java, and a depressingly easy one to screw up.
- Null-accepting alternatives would not be able to replace this pattern, and it's one that could use replacing.
- "Maybe" concepts from other languages aren't quite like Optional, or risk confusion with Optional, in their handling of null values. "Pain and ruin," as Kevin put it. (In Haskell, the closest analog to null is undefined, but Just undefined is still "present.")
- While I'd like Optional to be all kinds of things -- a functor! Even a monad! A burrito! -- I recognize that Java isn't always the most natural world for those things.
- If we're going to shoehorn those things into Java, we need, above all else, to carefully put those things in the most elegant, natural place possible, where they fit into the language as neatly as possible. Putting something in anywhere but the best place we can manage is a Bad Thing.
- In Haskell, there's a concept called "point-free" syntax, in which we express a function without ever referring to any variables -- just expressing it as a composition of other functions, or the result of more complicated function operators than composition. This syntax is also called "pointless" syntax, for the reason that it obfuscates terrifically if you don't use it sparingly. If a functional programming style obfuscates in Haskell, a language meant for such things, then in Java it can only be an atrocity.
- I am against writing libraries that make it easier to write atrocities, except where there have been very convincing arguments that the benefits outweigh the consequences. Thus, debate, but err on the side of "no atrocities."
That said: -1 to !Options.absent().equals(Options.absent()), and I'm not clear on what signature or meaning this "otherwise" method would have, though I like the name.
A method to turn this into Iterable though would be nice. I don't care about the for-each syntax, but having Iterables#concat work with lots of optional values would be sweet. I think it's a perception problem, and people can be educated (stackoverflow and javadocs would help), to make the perceived "weirdness" in extending Iterable vanish eventually. I would +1 going that way (but lets not turn this into a democracy!)
Ok, I'll add one more message. I suspect that the most common way one is going to end up having an iterable of optionals is using a transform function on an iterable of objects that contain an optional. So it would be a small cost in changing such a function from x.getOptionalFoo() to getOptionalFoo().asSet(), as/if needed. So let's ignore the subtyping I mentioned.
(Oh, instead of asList() though, i'd prefer an asSet() returning ImmutableSet, if something like this is added at all)
Sorry for the noise!
<B> B fold(Function<T, B> n, Function<T, B> s)
This is really the essence of the Optional type. With it, you can
implement everything else - get, getOrElse, isDefined, map/transform,
equals, hashCode, toString, everything else you can think of
or filterPresent()? allPresent() sounds like it should return a Boolean.
Blair
On Wed, Apr 27, 2011 at 1:44 AM, Jed Wesley-Smith <jed.wes...@gmail.com> wrote:
Kevin, it is fantastic to finally have a somewhat standard Option class in a common library, but almost every implementation I have seen follows the scala/haskell idiom of Option/Some/None. Is there any chance of following this convention rather than inventing a new mostly similar one?I am not expecting all of the functionality, just the basic naming, use Option<T> with Some and None concrete implementations.I think it's better not to raise the expectations of Scala and Haskell devotees by using such suggestive names.
- please (please) add Option<S> transform(Function<T, S> f)
- or implement Iterable<T> so we can wire that up ourselves
Not sure what you're asking for here.
+1 on Range *not* implementing Predicate. Ranges.asPredicate( Range )
seems to be a better place for that functionality.
- Ray A. Conner
> Optional<T>:http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/co...
On Apr 25, 2:06 pm, Kevin Bourrillion <kev...@google.com> wrote:
> Here are some new things we're looking at including in release 10 of Guava,
> slated for June 30:
>
>
> Range<C>:http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/co...http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/co...
>
> Uninterruptibles:http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/co...
>> <http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/co...>http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/co...
> New allAsList() and successfulAsList() methods in Futures:
>
> --
> Kevin Bourrillion @ Googlehttp://guava-libraries.googlecode.com
public C bound( C value ) {
if( value < lower ) return lower;
else if( value > upper ) return upper;
else return value;
}
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
Sets are predicates and predicates are sets; these are equivalent and completely interchangeable notions. java.util.Set is a mathematical set (contains) *plus* enumeration. Thus it would have made complete sense for java.util.Set to subtype Predicate. It would also make sense to rename Predicate to Set and Set to IterableSet. Eg filter(predicate) would become filter(Set), 'filter anything contained in that set'. Hypothetically speaking of course.
Sets are predicates and predicates are sets; these are equivalent and completely interchangeable notions.
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
Ah, that's nice.getup
On Tue, May 10, 2011 at 2:03 PM, Kevin Bourrillion <kev...@google.com> wrote:
Actually, all this is definitely in flux. I'm currently liking this
Actually, all this is definitely in flux. I'm currently liking this getup:
Optional<T> or(Optional<T> secondChoice)
--guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
This will require an explicit unsafe cast under the hood, but as Optional is immutable, that shouldn't be a problem.
This will require an explicit unsafe cast under the hood, but as Optional is immutable, that shouldn't be a problem.In fact, I did something in Optional's javadoc I'd never done before:* @param <T> the type of instance that can be contained. {@code Optional} is naturally covariant on* this type, so it is safe to cast an {@code Optional<T>} to {@code Optional<S>} for any* supertype {@code S} of {@code T}.I'm on the fence as to whether we should repeat that kind of text on other safely covariant and contravariant types in our library.
Why this wasn't allowed as legal in Java generics is still beyond me:@SuppressWarnings("unchecked")
public <T2 super T> Optional<T2> cast() { return (Optional)this; }
I assume it would take too much work to make the java compiler sufficiently smart to grok co-/contra-variant type parameters. If you do want such a smart compiler, use scala.
@SuppressWarnings("unchecked")
<T, Y extends T, X extends T> Option<T> or(Option<Y> left, Option<X> right){
return left.isDefined() ? (Option<T>) left : (Option<T>) right;
}
The following tests work:
@Test public void or(){
Option<Double> l = Option.some(.2);
Option<Integer> r = Option.some(1);
Option<Double> n = Option.none();
Option<Number> or = this.<Number, Double, Integer> or(l, r);
assertEquals(l, or);
Option<Number> or2 = this.<Number, Double, Integer> or(n, r);
assertEquals(r, or2);
}
The eclipse compiler can infer the type parameter from or(l, r) but
javac can't. So it's somewhat useless.
Thomas
Would anyone care to weigh in on whether the same approach toward nullability seems valuable for Holder<T> (the mutable version of this, which really is just about exactly the same as AtomicReference<T>)?
We're considering taking the same approach, which ends up with Holder having something like 11 methods, or just going with the much simpler, "it holds a nullable reference" approach (making it even more exactly like A.R.).
On Wednesday, May 11, 2011 4:50:15 PM UTC-4, Kevin Bourrillion wrote:Would anyone care to weigh in on whether the same approach toward nullability seems valuable for Holder<T> (the mutable version of this, which really is just about exactly the same as AtomicReference<T>)?I think it would only really apply if Holder was intended to be a mutable implementing subclass of Optional. Something that is just an indirection to a reference variable seems more like... just an indirection to a (nullable) reference variable.
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
I don't think an immutable class (Option) should have a mutable subclass (Holder). I don't like the other way round either, when it can be avoided (unlike in case of Set and ImmutableSet). In case Holder should be that similar to Option, I'd propose a common superclass
Right. This does incur some runtime overhead, which a Holder wouldn't have.
I'm waffling on my own opinion of which way it should go, but:
* if a mutable version of Optional, both classes should implement a
common interface for the get-related methods
* if a non-atomic version of AtomicReference, it should be nullable
just like AtomicReference.
Incidentally, I have so far refused to make Holder's field volatile, on the grounds that anyone who needs that reeaally should be using AtomicReference instead.
final Holder<MyType> result = ...;exec.execute(new Runnable() {public void run() { result.set(computeResult()); } // poor man's submit});// Subsequent poll for result won't work -- no h-b edge between result.set and poll attempts.
Effectively, it's "volatile" enough for most users. Since everything
is accessed by method (not field), the pre-set() value is not cachable
by external code.
Huh?
http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#17257
The frame of local variables in the execution of get() is flushed when
the method returns. When get() is invoked again, it will access the
field again from scratch. The importance of the volatile qualifier
comes in basically when code is executing a longer-lived method (the
field is accessed multiple times in the *same* method):
http://java.sun.com/docs/books/jvms/second_edition/html/Threads.doc.html#22258
That says, effectively, that volatile variables in the source code
must be compiled differently (they cannot be cached in the local
variable pool of the current frame; a "getfield" opcode must be
invoked every time).
And I'm saying that is incorrect, according to the JVM spec to which I
linked. Since get() and set() are _method calls_ rather than simple
field accesses, nothing about the field hidden inside Holder will be
cached by Thread2. This means Thread2, when it calls get() again, will
re-access the field from scratch, and _will_ see the new value set by
Thread1... regardless of whether the field is internally declared
volatile.
I don't know what you mean. Unless there's some form of synchronization or volatile, set() in one thread won't be visible to get() in another.I can't see the Holder code, though.
* if a mutable version of Optional, both classes should implement acommon interface for the get-related methods
I've run into plenty of instances, with my simpler nullable-cell type
tree, where immutable and mutable instances were both desirable, but I
wanted methods not doing mutable operations to accept a single
(read-only) interface in parameters to work with either one. Of
course, in my case there was only a get() method, but this seems to
extend to the Optional/Holder case too IMO.
On Thu, May 12, 2011 at 8:04 AM, Tim Peierls <t...@peierls.net> wrote:I don't know what you mean. Unless there's some form of synchronization or volatile, set() in one thread won't be visible to get() in another.I can't see the Holder code, though.voila:It is NOT certain to stay in this form.
On Thu, May 12, 2011 at 7:26 AM, Todd Vierling <t...@duh.org> wrote:* if a mutable version of Optional, both classes should implement acommon interface for the get-related methodsThat they should do this was sort of an axiomatic truth for me, but when asked to justify the real benefits of creating a type hierarchy, I couldn't quite do it. Can anyone explain convincingly why we should need to interface with a Holder or an Optional polymorphically?
I think I see the source of the confusion. Todd is correct when he
states:
"The frame of local variables in the execution of get() is flushed
when the method returns."
The field within the Holder
instance is not on the stack, not in that "frame of local variables"
at all. In fact, the fields of an object instance can't be on the
stack, although a reference to an object could be.
Warning: pure speculation follows.We hope to keep going and ponder RangeSet eventually; something like:
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
>> You're partly correct about my confusion. I was primarily
>> conflating bytecode compilation (which has specific rules on volatile, in
>> that every read access requires a getfield as opposed to caching in
>> the local variable pool) with JIT's behavior (which may elide the flush
>> of the reference, and turn multiple getfields into multiple accesses to
>> a cached value).
I meant that JIT may elide the flush or turn multiple getfields into
cache hits for members _not_ marked "volatile". That's the difference
noted in the JVM spec cited to me earlier, chapter 14, which deals
with memory (rather than bytecode) aspects of "volatile".