light weight types
in [Java Help]
|
Prev: Putting passwords in a properties file?
Next: Interview
From: Lew on 3 Oct 2009 22:02 Roedy Green wrote: > Generics lack the elegance of other Java features. The syntax is ad > hoc, unshaved, irregular, Perlish, unfinished. Generics syntax is just fine, taken for what it is. Most people's trouble lies in their attempt to make it something other than what it is. I'm not saying generics is the easiest thing in the universe - it has to express type analysis, and we programmers are not most of us used to doing type analysis. Unfamiliarity makes it seem even harder. But it's not the ridiculously insurmountable pinnacle you're trying to claim it is. Generics syntax is a declarative calculus for type assertions. As such it is very, very powerful. I also have observed that generics do not add to the complexity of type analysis - it's type analysis that is hard. Generics has close to a half dozen syntactic elements: <> ? extends super T When you say static <T> void sort( List<T> list, Comparator<? super T> c ) you are simply declaring that the 'compareTo' method can handle some supertype of T, and therefore can compare T as well. Where people run into trouble is having two different <? extends Foo> expressions and expecting one "some subtype of Foo" to be the same as the other "some subtype of Foo" when the two captures express no such connection. And also when they don't read the explanatory material. > With most features, you have and ah ha moment, and all falls into > place. Everything is as it should be. It could be no other plausible > way. You "grok" them in fullness, and no longer need to read a manual > to write code. Generics don't do that, at least not yet. I had that "ah-hah" moment. I'm sorry that you haven't, yet. Read the materials I keep referencing and you should have it, too. At the very least you'll develop useful rules of thumb that make it possible to use generics. I've watched several other programmers approach generics for the first time and get that "ah-hah" also, usually within a few days of reading the recommended materials if they're experienced Java programmers. So I'm not claiming that I'm anything special here. <http://java.sun.com/docs/books/effective/> - free chapter on generics <http://www.ibm.com/developerworks/java/library/j-jtp04298.html> <http://www.ibm.com/developerworks/java/library/j-jtp07018.html> Read, and say, "Ah-hah!" -- Lew
From: Lew on 3 Oct 2009 22:05 Joshua Cranmer wrote: > Types can also be recursive. A recursive type is something of the form > class Foo<T extends Foo<T>>. You generally subclass or implement > interfaces of these form in the fashion class Bar extends Foo<Bar>. The > purpose of a recursive type is to operate on itself in some fashion: > think of Comparable's compareTo method. Classes implementing Comparable > only compare objects of the same class as them, not of other classes > implementing Comparable. However, be careful not to think of the generic parameter declaration as any kind of operation. "<T extends Foo<T>>" is not an operation. It is an assertion about the limitations on the type. It was this shift from procedural thinking to declarative thinking that made generics make sense to me. -- Lew
From: John B. Matthews on 3 Oct 2009 22:24 In article <ha8luq$pd2$1(a)news.eternal-september.org>, Jeff Higgins <oohiggins(a)yahoo.com> wrote: > John B. Matthews wrote: > > In article <ha7fvl$8g0$1(a)news.eternal-september.org>, > > Jeff Higgins <oohiggins(a)yahoo.com> wrote: > > > >> John B. Matthews wrote: > >>> In article <7ig1fsF319h9fU1(a)mid.individual.net>, > >>> Mike Amling <mamling(a)rmcis.com> wrote: > >>> > >>>> Surely someone somewhere must have something like this already, with > >>>> classes or interfaces for time, distance, mass, etc. > >>> JSR-275: <http://jscience.org/api/index.html> > >>> > >> <https://jscience.dev.java.net/servlets/ReadMsg?list=dev&msgNo=654> > > > > Thank you for responding. I'm not sufficiently familiar with the process > > to understand the import of the discussion you cited. The measure > > package was moved to javax.measure in anticipation of standardization as > > part of JSR-275. Failing that, the code still seems useful. Is there > > some reason to be wary? > > The JSR process is opaque. > I would rather have seen another development process chosen, > and the measure.* packages remain in the jscience namespace. > I am not certain what benefit the API of the measure.* > packages accrue from becoming a 'standard technical specification'. > The code is useful, available, and liberally licensed. > The JSR process is opaque. Ah, I think I see what you mean. I recall stumbling over the namespace change initially, but I can empathize with the authors' pride of workmanship. In a different example, the class javax.swing.SwingWorker was introduced in Java 1.6, but identical functionality is available in Java 1.5 as org.jdesktop.swingworker.SwingWorker. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Joshua Cranmer on 3 Oct 2009 22:32 On 10/03/2009 10:05 PM, Lew wrote: > Joshua Cranmer wrote: >> Types can also be recursive. A recursive type is something of the form >> class Foo<T extends Foo<T>>. You generally subclass or implement >> interfaces of these form in the fashion class Bar extends Foo<Bar>. >> The purpose of a recursive type is to operate on itself in some >> fashion: think of Comparable's compareTo method. Classes implementing >> Comparable only compare objects of the same class as them, not of >> other classes implementing Comparable. > > However, be careful not to think of the generic parameter declaration as > any kind of operation. "<T extends Foo<T>>" is not an operation. It is > an assertion about the limitations on the type. I suppose I could have written that better. A better sentence: The primary purpose of a recursive type is to allow the creation of generic interfaces whose methods require the use of the implementing class as parameters. Comparable objects compare only to other objects of the same class, but the Comparable interface allows you to reason about objects that have a defined total ordering. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Kevin McMurtrie on 3 Oct 2009 23:59
In article <d93fc5hq94qqdpekq4aqpcurj9sapu2vj3(a)4ax.com>, Roedy Green <see_website(a)mindprod.com.invalid> wrote: > On Mon, 28 Sep 2009 23:25:39 -0700, Kevin McMurtrie > <kevinmcm(a)sonic.net> wrote, quoted or indirectly quoted someone who > said : > > >(And yet the simple things > >like unsigned math > > A ubyte type could be added without even changing the JVM. The > compiler could even just mindlessly add in & 0xff after every load. > There might be a problem finding bits to accommodate ubyte in the byte > codes. > > for a uint, it not that onerous to use long and &0xffffffff; manually For complex number crunching, all of that masking and casting makes the code a complete mess - a total loss for maintainability. That mess also runs half as fast on x86 and x86-64. > for a ulong you truly need unsigned arithmetic. But one extra bit in > 64 is not that big a prize. > > My thinking is, ubyte is the main thing to go for. The current signed > bytes are too error prone, since 99% of the time you want ubyte. -- I will not see your reply if you use Google. |