Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #31092

Re: "null", polymorphism and TCO

Show all headers | View raw

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.

Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: "null", polymorphism and TCO Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-02-08 23:06 -0800
  Re: "null", polymorphism and TCO Marcel Mueller <news.5.maazl@spamgourmet.org> - 2015-02-09 11:36 +0100
    Re: "null", polymorphism and TCO Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-02-09 20:35 -0800
      Re: "null", polymorphism and TCO Marcel Mueller <news.5.maazl@spamgourmet.org> - 2015-02-10 10:37 +0100
        Re: "null", polymorphism and TCO Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-02-10 12:51 -0600

csiph-web