Re: "null", polymorphism and TCO
A simple hasNext() method is easier.
What I really dislike is the JRE implementations of BlockingDeque and
BlockingQueue. There's no "close" and adding null is forbidden so it's
a pain in the ass to terminate a queue and its waiters.
If Oracle ever optimizes away the String(String) constructor it's going
to break a lot of code where I have to terminate String queues with
something like this:
static final String endOfQueue= new String("end");
...
while ((item= queue.take()) != endOfQueue)
{
...
}
queue.put(endOfQueue);
When it's OK to import libraries I use my own queue that has a close()
method.
In article <null-20150208185452@ram.dialup.fu-berlin.de>,
ram@zedat.fu-berlin.de (Stefan Ram) wrote:
A book said that one needed null to mark the end of a linked
list:
class Entry { java.lang.String text; Entry next; };
public final class Main
{ public static void main( final java.lang.String[] args )
{ Entry first = new Entry(); first. text = "first";
Entry second = new Entry(); second.text = "second";
first.next = second;
Entry last = new Entry(); last.text = "third";
second.next = last;
for
( Entry current = first; current != null;
current = current.next )
java.lang.System.out.println( current.text ); }}
This prints:
first
second
third
Neither null nor java.util.Optional is needed when one
is using polymorphism, i.e., real OOP. We just need to say
that an entry with a next entry is a different type than
an entry without a next entry. No ?null?, no ?Optional?,
just polymorphism!
abstract class Entry
{ java.lang.String text;
abstract void accept
( java.util.function.Consumer< java.lang.String >consumer ); }
class TerminationEntry extends Entry
{ void accept
( java.util.function.Consumer< java.lang.String >consumer )
{ consumer.accept( text ); } };
class ContinuationEntry extends Entry
{ Entry next; void accept
( java.util.function.Consumer< java.lang.String >consumer )
{ consumer.accept( text ); next.accept( consumer ); }};
public final class Main
{ public static void main( final java.lang.String[] args )
{ ContinuationEntry first = new ContinuationEntry();
first. text = "first";
ContinuationEntry second = new ContinuationEntry();
second.text = "second"; first.next = second;
TerminationEntry last = new TerminationEntry();
last.text = "third"; second.next = last;
first.accept( java.lang.System.out::println ); }}
This, too, prints:
first
second
third
But now, there is a case of recursion (in the method
?accept? of the class ?ContinuationEntry?). But it is
tail recursion. Now, this might be too far fetched,
but insofar one might say that proper OOP needs TCO
and hope that one day Oracle will find this out!
From a practical point of view, the null solution
seems to be a kind of optimization: When one wants
to append to a TerminationEntry, one first needs to
replace it by a ContinuationEntry. This wastes more
resources than just overwriting a null value.
--
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.