On Tue, Feb 26, 2013 at 5:47 AM, Paul Sandoz <span dir="ltr">&lt;<a href="mailto:paul.sandoz@oracle.com" target="_blank">paul.sandoz@oracle.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Feb 26, 2013, at 6:16 AM, Sam Pullara &lt;<a href="mailto:sam@sampullara.com" target="_blank">sam@sampullara.com</a>&gt; wrote:<br>
&gt; I&#39;ve never been comfortable with this. I&#39;m glad Jed is calling it out.<br>
&gt; Can we make Optional first class or remove it?<br>
<br>
</div>Trawling through the email archives i cannot find specific discussion on Optional.map/flatMap, anyone recall such discussion? There is some general discussion on not going down the route of an option monad.<br></blockquote>

<div><br></div><div>In particular, you wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">java.util.Optional has a narrower scope that optional things in other languages. We are not trying to shoe-horn in an option monad.</span> </blockquote>

<div><br></div><div>And I say amen to that. Keep Optional, and keep it lean and mean. (At least as lean as the Guava Optional.)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Since we have added a Stream.flatMap method following the pattern expected of it, does that give more weight to argument of adding such a method to Optional, perhaps of the same or a different name to disassociate with Stream itself?<br>

</blockquote><div><br></div><div>No, it doesn&#39;t. The two are unrelated. Stream is a lofty abstraction and Optional is (or should be) a grunt-level utility.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I find myself more and more leaning towards the position of if we include an Option class some developers will expect bind functionality, it seems useful, and nor is it hard to explain its use while avoiding mention the &quot;m&quot; word.<br>

</blockquote><div><br></div><div>The more you saddle Optional with &quot;might be useful&quot; and &quot;X might want this&quot; features, the harder it will be for regular people -- people who don&#39;t know what a monad is -- to assimilate and use Optional sensibly. One of the reasons Doug Lea is not an Optional fan is fear of things like Collection&lt;Optional&lt;T&gt;&gt;, something that is less likely to happen with a minimalist Optional.</div>
<div><br></div><div>Here&#39;s another reason to stay lean: The more limited Optional is, the easier it will be some day to optimize away the extra object. Make it a first class participant and you can kiss those optimizations goodbye. </div>
<div><br></div><div>--tim</div><div><br></div></div>