<?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: Almost Useful: Operator overloading</title>
	<atom:link href="http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/feed/" rel="self" type="application/rss+xml" />
	<link>http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/</link>
	<description>Daniel Pitts' Tech Blog</description>
	<pubDate>Sat, 22 Nov 2008 04:46:56 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Ricky Clarkson</title>
		<link>http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/#comment-54</link>
		<dc:creator>Ricky Clarkson</dc:creator>
		<pubDate>Wed, 05 Dec 2007 13:43:57 +0000</pubDate>
		<guid isPermaLink="false">http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/#comment-54</guid>
		<description>I agree in principle, though I don't feel strongly about it.  I'd like to suggest you take a look at how Haskell does it.  Even the built-in types, such as Integer, can only use +, -, * and / because they are a member of the Num typeclass (similar to implementing an interface).  So if you want to make a new type able to use those operators, you make the type an instance/member of the Num typeclass.  That means if you overload +, you have to overload *, etc., which arguably is better than allowing individual overloads.

You could also take a look at Scala, in which all that punctuation can disappear, which leaves normal method calls easier to read:

val s: Speed = endDistance minus startDistance divide duration;

It's evaluated left to right, by the way, divide can't have a higher precedence than minus, because they're both method calls.  I think there are languages in which a method call can decide its own precedence, but Scala isn't one of them.

So in general, for Java, I'd suggest some classes/interfaces that provide those operators.  You mentioned Comparable for &#60;, , &#62;=.  I think it seems a little strange for == to possibly contradict &#60;=, so I reserve judgement for now.

I suggest Number gains the necessary extra information to allow user classes to define their own +, -, * AND /, at least, and possibly an extra class/interface to add more esoteric things like %, a Bitwise interface for ~, ^, &#124;, &#38;.

I think a few small measures like this could allow operator overloading without sparking fears that Java is turning into C++ (the usual complaint, despite C++ being only one of many many languages that support operator overloading).</description>
		<content:encoded><![CDATA[<p>I agree in principle, though I don&#8217;t feel strongly about it.  I&#8217;d like to suggest you take a look at how Haskell does it.  Even the built-in types, such as Integer, can only use +, -, * and / because they are a member of the Num typeclass (similar to implementing an interface).  So if you want to make a new type able to use those operators, you make the type an instance/member of the Num typeclass.  That means if you overload +, you have to overload *, etc., which arguably is better than allowing individual overloads.</p>
<p>You could also take a look at Scala, in which all that punctuation can disappear, which leaves normal method calls easier to read:</p>
<p>val s: Speed = endDistance minus startDistance divide duration;</p>
<p>It&#8217;s evaluated left to right, by the way, divide can&#8217;t have a higher precedence than minus, because they&#8217;re both method calls.  I think there are languages in which a method call can decide its own precedence, but Scala isn&#8217;t one of them.</p>
<p>So in general, for Java, I&#8217;d suggest some classes/interfaces that provide those operators.  You mentioned Comparable for &lt;, , &gt;=.  I think it seems a little strange for == to possibly contradict &lt;=, so I reserve judgement for now.</p>
<p>I suggest Number gains the necessary extra information to allow user classes to define their own +, -, * AND /, at least, and possibly an extra class/interface to add more esoteric things like %, a Bitwise interface for ~, ^, |, &amp;.</p>
<p>I think a few small measures like this could allow operator overloading without sparking fears that Java is turning into C++ (the usual complaint, despite C++ being only one of many many languages that support operator overloading).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chaotic Java &#187; Blog Archive &#187; Who wants Indexer as the next EoD feature?</title>
		<link>http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/#comment-53</link>
		<dc:creator>Chaotic Java &#187; Blog Archive &#187; Who wants Indexer as the next EoD feature?</dc:creator>
		<pubDate>Wed, 05 Dec 2007 07:11:03 +0000</pubDate>
		<guid isPermaLink="false">http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/#comment-53</guid>
		<description>[...] fact, just today Daniel Pitts posted something about it under his “almost useful” tag. In that, he obviously mentions the convenient square brackets [...]</description>
		<content:encoded><![CDATA[<p>[...] fact, just today Daniel Pitts posted something about it under his “almost useful” tag. In that, he obviously mentions the convenient square brackets [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aviad Ben Dov</title>
		<link>http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/#comment-52</link>
		<dc:creator>Aviad Ben Dov</dc:creator>
		<pubDate>Wed, 05 Dec 2007 05:30:11 +0000</pubDate>
		<guid isPermaLink="false">http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/#comment-52</guid>
		<description>One of the problems Java has is that the collections framework was never a part of the designed language features, it was added later; therefore, it didn't get a "spot" like String, and you can see that only recently a "foreach" was added to reduce the verbosity of the Iterator class. 

To follow that line of logic (of adding ease of development features which make use of common interfaces, such as the Collection interface which was extracted into the Iterable interface), I see that it makes sense for the Java developers to add another EoD feature that relies on an Indexer interface which allows people to use the square-brackets-with-index syntax. 

Just my couple of cents, but now that I wrote it here I find it interesting and I might make a whole post about it on my blog ;)</description>
		<content:encoded><![CDATA[<p>One of the problems Java has is that the collections framework was never a part of the designed language features, it was added later; therefore, it didn&#8217;t get a &#8220;spot&#8221; like String, and you can see that only recently a &#8220;foreach&#8221; was added to reduce the verbosity of the Iterator class. </p>
<p>To follow that line of logic (of adding ease of development features which make use of common interfaces, such as the Collection interface which was extracted into the Iterable interface), I see that it makes sense for the Java developers to add another EoD feature that relies on an Indexer interface which allows people to use the square-brackets-with-index syntax. </p>
<p>Just my couple of cents, but now that I wrote it here I find it interesting and I might make a whole post about it on my blog <img src='http://virtualinfinity.net/wordpress/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aviad Ben Dov</title>
		<link>http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/#comment-51</link>
		<dc:creator>Aviad Ben Dov</dc:creator>
		<pubDate>Wed, 05 Dec 2007 05:12:54 +0000</pubDate>
		<guid isPermaLink="false">http://virtualinfinity.net/wordpress/almost-useful/2007/12/04/almost-useful-operator-overloading/#comment-51</guid>
		<description>It's easy to take a look at where operator overloading is the good case. But let's not forget that the operator overloading debate is a really old one, and goes back at least 10 years in the life of Java. Take a look at a &lt;a href="http://chaoticjava.com/posts/operator-overloading-debate/" rel="nofollow"&gt;similar post of mine&lt;/a&gt;, I wrote some about it and in a much better way than I'd bring in a comment here. :)</description>
		<content:encoded><![CDATA[<p>It&#8217;s easy to take a look at where operator overloading is the good case. But let&#8217;s not forget that the operator overloading debate is a really old one, and goes back at least 10 years in the life of Java. Take a look at a <a href="http://chaoticjava.com/posts/operator-overloading-debate/" rel="nofollow">similar post of mine</a>, I wrote some about it and in a much better way than I&#8217;d bring in a comment here. <img src='http://virtualinfinity.net/wordpress/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
</channel>
</rss>
