<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Revisiting Maybe in Java</title>
	<atom:link href="http://blog.tmorris.net/revisiting-maybe-in-java/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.tmorris.net/revisiting-maybe-in-java/</link>
	<description>The weblog of Tony Morris</description>
	<pubDate>Tue, 06 Jan 2009 12:25:02 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: λ Tony&#38;#8217;s blog λ &#38;#187; Blog Archive &#38;#187; Maybe Monad in Java</title>
		<link>http://blog.tmorris.net/revisiting-maybe-in-java/#comment-30</link>
		<dc:creator>λ Tony&#38;#8217;s blog λ &#38;#187; Blog Archive &#38;#187; Maybe Monad in Java</dc:creator>
		<pubDate>Mon, 18 Dec 2006 04:10:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tmorris.net/revisiting-maybe-in-java/#comment-30</guid>
		<description>[...] As I have shown previously, the problem of partial function in Java is not easily solved. The solution of the Maybe algebraic data type, while definitely superior to existing options, is cumbersome to implement and requires some functions defined over the type (isJust, isNothing, etc.) in order to be complete. As some point out, there is a preference for continuation passing to prevent the need for a cast (even though this case would be hidden). This prompted me to provide a more complete solution - which is still only a subset of a complete solution. [...]</description>
		<content:encoded><![CDATA[<p>[...] As I have shown previously, the problem of partial function in Java is not easily solved. The solution of the Maybe algebraic data type, while definitely superior to existing options, is cumbersome to implement and requires some functions defined over the type (isJust, isNothing, etc.) in order to be complete. As some point out, there is a preference for continuation passing to prevent the need for a cast (even though this case would be hidden). This prompted me to provide a more complete solution - which is still only a subset of a complete solution. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ricky Clarkson</title>
		<link>http://blog.tmorris.net/revisiting-maybe-in-java/#comment-29</link>
		<dc:creator>Ricky Clarkson</dc:creator>
		<pubDate>Thu, 16 Nov 2006 23:42:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tmorris.net/revisiting-maybe-in-java/#comment-29</guid>
		<description>Again with the [] for generics..

I think that you pass a NothingC[Q] to the maybe method instead of a Q directly to facilitate lazy evaluation.  I went down this road with my functional stuff, and I found that I just didn't need it.  It's simpler to be able to pass 5 to a method, rather than calling some wrapping, e.g., new NonNullNothingC[Integer](5).

It is quite rare that I have a case where calculating that value is expensive.  Of course, it happens, and that's when I choose laziness, but I don't have to force laziness on the rest of my code.

I have a badly named interface, Returner, which is rather like your NothingC, and if I want laziness then I make the Function (Function is called JustC in your post) that I pass as the first parameter to accept (accept is called maybe in your post) return a Returner[Q] and make the second parameter a Returner[Q] also.

This is quite rare, and usually indicates that I'm doing stuff with side-effects anyway, so I probably need a good old refactor.

Implementing the Either type from Haskell is a nice exercise in Java too - again, done it already, although I called my accept method 'visit', stupidly..

http://functionalpeas.googlecode.com/svn/trunk/src/fpeas/either/</description>
		<content:encoded><![CDATA[<p>Again with the [] for generics..</p>
<p>I think that you pass a NothingC[Q] to the maybe method instead of a Q directly to facilitate lazy evaluation.  I went down this road with my functional stuff, and I found that I just didn&#8217;t need it.  It&#8217;s simpler to be able to pass 5 to a method, rather than calling some wrapping, e.g., new NonNullNothingC[Integer](5).</p>
<p>It is quite rare that I have a case where calculating that value is expensive.  Of course, it happens, and that&#8217;s when I choose laziness, but I don&#8217;t have to force laziness on the rest of my code.</p>
<p>I have a badly named interface, Returner, which is rather like your NothingC, and if I want laziness then I make the Function (Function is called JustC in your post) that I pass as the first parameter to accept (accept is called maybe in your post) return a Returner[Q] and make the second parameter a Returner[Q] also.</p>
<p>This is quite rare, and usually indicates that I&#8217;m doing stuff with side-effects anyway, so I probably need a good old refactor.</p>
<p>Implementing the Either type from Haskell is a nice exercise in Java too - again, done it already, although I called my accept method &#8216;visit&#8217;, stupidly..</p>
<p><a href="http://functionalpeas.googlecode.com/svn/trunk/src/fpeas/either/" onclick="javascript:pageTracker._trackPageview('/outbound/comment/functionalpeas.googlecode.com');" rel="nofollow">http://functionalpeas.googlecode.com/svn/trunk/src/fpeas/either/</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
