tag:blogger.com,1999:blog-741750605858169835.post270236523494333338..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: JSR-310 and Java 7 language changesStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger32125tag:blogger.com,1999:blog-741750605858169835.post-26808745019441403512007-10-18T08:03:54.000+01:002007-10-18T08:03:54.000+01:00My own pet project:
http://pec.dev.java.net/nonav...My own pet project:<br /><br />http://pec.dev.java.net/nonav/compile/index.html<br /><br />Is an extended compiler for patterns, one of the patterns is immutable. The compiler uses a marker interface and enforces immutability.Howard Lovatthttp://pec.dev.java.net/nonav/compile/index.htmlnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-50766754000729487622007-10-13T14:27:23.000+01:002007-10-13T14:27:23.000+01:00@Casper, thanks for the link - I'll have to po...@Casper, thanks for the link - I'll have to post about operator overloading separately soonStephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-50169768937787241772007-10-13T02:53:52.000+01:002007-10-13T02:53:52.000+01:00Donno if you have seen it Stephen, but your reason...Donno if you have seen it Stephen, but your reasoning is being challanged on this blog:<br />http://cafe.elharo.com/java/operator-overloading/<br /><br />(Still trying to figure out what group and a ring he is referring to.)<br /><br />/CasperCasper Bangnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-41238308684651270532007-10-13T00:18:38.000+01:002007-10-13T00:18:38.000+01:00@Osvaldo, Thanks for the performance indication on...@Osvaldo, Thanks for the performance indication on BigDecimal. Maybe we need the bytecode extensions being discussed elsewhere (MLVM) to include decimal/rational handling.<br /><br />@Kevin, I'll blog more about my opinion on Scala at some point :-)<br /><br />@Neils, Your singleton, related to immutable, is another design pattern that would be better expressed in the language.<br /><br />@Paul, Your explanation on duration adds the clarity which I didn't quite get to. The best approach will probably end up being one class for scientific precise durations, and another for human-scale durations/periods like days & months.<br /><br />BTW, I don't entirely agree that 2.3 days is not useful. At work I can enter 2.5 hours into my time-recording program. However it is instantly converted to 2 hours 30 minutes, so perhaps the double is just used as a constructor/factory, and int used internally.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-76180295465651159332007-10-12T19:39:00.000+01:002007-10-12T19:39:00.000+01:00I think there's a lot of people who don't ...I think there's a lot of people who don't understand why we need a Duration object. Why not just a number of milliseconds? Well, because not all days are created equal. Where I live, in a place with daylight saving time, one day each year has 23 hours and one day has 25 hours. The other days all have 24 hours. Likewise (and more obviously) not all months have the same number of days.<br /><br />Any proposed implementation of Duration that doesn't take these basic requirements into account isn't worth implementing. So, just a number of milliseconds isn't good enough. And likewise neither float nor BigDecimal is of any use in a Days object. "6 days" makes sense, but "2.3 days" doesn't.<br /><br />I know you weren't talking about that specifically, you were just using it as an example to beat on the Java language designers. But clearly there's a lot of responders that don't get it.Paul Claphamnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-11182445552215503802007-10-10T16:43:52.000+01:002007-10-10T16:43:52.000+01:00It seems to me that, sadly, there was never any re...It seems to me that, sadly, there was never any real thought given to the treatment of mutability and immutability in the Java libraries. An excellent counter-example can be found in Apple's Cocoa frameworks (most notably in the Foundation framework), which establish the convention that immutable classes are base classes that have mutable descendants.<br /><br />Setter methods for immutable properties are declared in subclasses. The root class (NSObject) implements copy() and mutableCopy() methods that can be overridden as necessary by subclasses ('copy' being somewhat analagous to Java's clone() method), meaning that any mutable instance can provide an immutable copy of itself, and vice versa, through a simple and pervasive API.<br /><br />Come to think of it, it might be helplful to take a look at how time intervals are handled in the Foundation framework. I haven't worked with Cocoa in a while, but as I <br />recall, its handling of dates and time values was fairly elegant. I know the Foundation framework represents time intervals as a double (typedefed as NSTimeInterval), where the integral portion represents seconds. I'm not sure precisely what the code does under the covers to manage rounding issues, but I can't imagine that it would be all that daunting.Jonathan Lehrhttp://www.jroller.com/page/JonathanLehrnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-22337946554317019652007-10-10T09:32:15.000+01:002007-10-10T09:32:15.000+01:00I do not have any opinion on BigDecimal, self type...I do not have any opinion on BigDecimal, self types and operator overloading right now, but I like what you say about immutable at language level.<br />It is actually the case where we as programmers face an idiom, which we currently signifies as design patterns, similar to Singleton, Builder, Decorator etc.<br />What about:<br />public singleton mySingleton {<br /> ...<br />}<br />or<br />public class CRCOutputStream decorate OutputStream {<br />...}<br /><br />This is basically a need for a domain specific language for ourselves, which I occasionally have used precompilers to address..<br />There are some existing magics already (take for instance transient...).<br /><br />But basically, couldn't much of the trouble be avoided using @annotations?Niels Bech Nielsenhttp://www.javaekspert.dknoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-27176265519260540342007-10-08T23:24:12.000+01:002007-10-08T23:24:12.000+01:00For a duration type class I have been using an imm...For a duration type class I have been using an immutable class that represents a starting and ending time (DateRange). My common use case is to do something for every nth interval where the interval could be hours, days, weeks, etc. For this I have an iterator class that takes the range, the interval, and an instance of a class representing the function to perform. At the application level you can define a constant range and use it with any number of constant iterators. The iterator can use any of the basic calendar intervals or be user defined such as Friteenth (friday before 3rd sunday).Stevenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-27980696267330210982007-10-08T22:33:54.000+01:002007-10-08T22:33:54.000+01:00Slava Pestov is right about Java folks not taking ...Slava Pestov is right about Java folks not taking time to expand their minds a little and learn from other languages like Scala, OCaml, ML, Haskell...<br /><br />Microsoft is doing massive amounts of language R&D right now and C# 3.0 is the result. They aren't sitting still either -- they will be taking on the multi-core problem next.<br /><br />The Scala guys are on the right track.Kevinnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-79869125558249366312007-10-08T20:13:25.000+01:002007-10-08T20:13:25.000+01:00On immutable, a simpler approach is to use a marke...On immutable, a simpler approach is to use a marker interface. This makes it possible to identify an immutable object using existing Java syntax. As for performance gains, a compiler could already recognise a class that had no mutators and was thus immutable. However, another property often suggested in conjunction with immutability is value semantics --- where == maps to equals(). This does allow efficiency gains at least for small objects. In particular arrays can just contain the values instead of references to objects. This saves a reference and an object header for every entry.Mark Thorntonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-37292121665635670732007-10-08T20:03:11.000+01:002007-10-08T20:03:11.000+01:00While some languages already have rational type li...While some languages already have rational type libraries, I think it unlikely that future general purpose languages would offer rationals instead of decimal/double/float. For all their complications, floating point types are just too useful (and have good hardware support). After all why do people spend so much time agonising over differences in the 15th decimal place of measurements that are only accurate to 6 places anyway? And of course why did they print all 15 places?<br /><br />Back to durations. What are you trying to achieve with fractional days anyway? Why not just measure durations in double seconds. A double can represent integer seconds exactly up to 2^53 (quite a while!). This means that all the 'human' scale durations are represented exactly, while still handling other values seamlessly. Formatters (and conversions to days:hours:minute ... representations) will require some care in implementation, but this need only be done once.Mark Thorntonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-77035585474874541622007-10-08T19:10:18.000+01:002007-10-08T19:10:18.000+01:00On BigDecimal: the performance is acceptable for m...On BigDecimal: the performance is acceptable for most apps that REALLY need this (e.g., financial stuff), but it's still a couple orders of magnitude slower than primitive numeric types. Depending on the algorithms you plan to have there, BigDecimal is still a no-no; especially algorithms that require iteration - a for loop that creates thousands of BigDecimal objects is still a pain, even with modern GCs. The lack of mutable BigInteger/BigDecimal types is a huge blunder. (I implemented a Mandelbrot generator with BigDecimal, and it sucks ass.)<br /><br />On 'immutable' keyword: Not necessary, this is a very good use case for annotations (JSR-305 should be a good host for an @Immutable annotation).Osvaldo Pinali Doederleinhttp://weblogs.java.net/blog/opinali/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-7372331607713166282007-10-08T18:21:17.000+01:002007-10-08T18:21:17.000+01:00@Mark, the same thought on 1/60 has been on my min...@Mark, the same thought on 1/60 has been on my mind too. Is there any reason why a future language wouldn't offer rational fraction as a basic numeric type (instead of decimal/double/float)?<br /><br />@David, I agree that there is more than one solution to the issues/use cases I raised, and operator overloading is only part of the problem. Aliasing types (separately) could easily be part of the solution.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-38749621337984462252007-10-08T17:59:23.000+01:002007-10-08T17:59:23.000+01:00> public immutable class DateTime
So you are a...> public immutable class DateTime<br /><br />So you are asking for a "const" keyword?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-80419211296947246452007-10-08T17:00:16.000+01:002007-10-08T17:00:16.000+01:00Because 1/60 doesn't have an exact BigDecimal ...Because 1/60 doesn't have an exact BigDecimal representation, BigDecimal isn't really any better for the value of Days than double (or float). You would need to use some sort of rational fraction to avoid the same sort of unexpected results as plague naive users of binary floating point types.Mark Thorntonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-83619989450095947492007-10-08T14:38:42.000+01:002007-10-08T14:38:42.000+01:00Operator Overloading isn't necessary if you ta...Operator Overloading isn't necessary if you take an alternate approach in the object model. If you allow for logical definition of numeric types as a subset of an existing numeric type, you'd be able to have separate classes for apples and oranges such that you can do basic arithmetic with either apples or oranges but you can't mix them. Sun has, so far, not been terribly receptive of this alternative.David Hallhttp://jroller.com/page/dhallnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-85996850678845787502007-10-08T12:28:13.000+01:002007-10-08T12:28:13.000+01:00"My immutable point was that if the compiler ..."My immutable point was that if the compiler and hotspot runtime had the info that an object is immutable, then certain performance optimisations become possible"<br /><br />Is there any information you can give to support that statement? (Not that I don't believe you, I just want to see if it would be worth it)quintessenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-88904088371703243912007-10-08T05:47:02.000+01:002007-10-08T05:47:02.000+01:00Your use case for self types is also false. How ca...Your use case for self types is also false. How can you be sure that addition is carried out the same way in different sub-classes of AbstractDateTime? I would say it is more likely that it isn't, that different sub-classes would represent different time systems with different basic units that would be converted. Or, if not very dfferent units, at least different precisions which amounts to basically the same thing.<br /><br />The different precisions is what makes your BigDecimal use case false, too, by the way.<br /><br />I am glad you are starting to see my point about immutable classes, though.Torbjörn Gannholmnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-76815745738567570282007-10-07T23:44:53.000+01:002007-10-07T23:44:53.000+01:00... and the method signature shoudl be really:
T ...... and the method signature shoudl be really:<br /><br />T plusYears() { return (T)new AbstractDateTime(); }Fabrizio Giudicihttp://weblogs.java.net/blog/fabriziogiudici/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16245338884805577182007-10-07T23:44:11.000+01:002007-10-07T23:44:11.000+01:00Of course the last line in the code above should b...Of course the last line in the code above should be:<br /><br /> DateTime2 dt2b = dt2a.plusYears();Fabrizio Giudicihttp://weblogs.java.net/blog/fabriziogiudici/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-6203968189664211802007-10-07T23:42:49.000+01:002007-10-07T23:42:49.000+01:00PS Couldn't the 'self type' be replace...PS Couldn't the 'self type' be replaced by this?<br /><br />class AbstractDateTime <br /> {<br /> T plusYears() { return (T)new AbstractDateTime(); }<br /> }<br /><br />class DateTime1 extends AbstractDateTime<br /> {<br /> }<br /><br />class DateTime2 extends AbstractDateTime<br /> {<br /> }<br /><br /><br /><br />class X<br /> {<br /> public void method()<br /> {<br /> DateTime1 dt1a = new DateTime1();<br /> DateTime1 dt1b = dt1a.plusYears();<br /> DateTime2 dt2a = new DateTime2();<br /> DateTime2 dt2b = dt1b.plusYears();<br /> }<br /> }Fabrizio Giudicihttp://weblogs.java.net/blog/fabriziogiudici/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-87794895613965095562007-10-07T23:33:51.000+01:002007-10-07T23:33:51.000+01:00Maybe it's just that it's too late, but I ...Maybe it's just that it's too late, but I don't understand this at all.<br /><br />1. BigDecimal. So there are not operators and you'll have to use method calls. It sounds crazy to me that this prevents somebody from using a certain data type. For instance I don't understand how people managed in designing Vector and Matrix libraries, that of course have the same problem, but in some really really worse instantiation.<br /><br />2. Immutable. I don't understand what the 'immutable' would do that we can't do by putting 'final' on all fields. And which kind of optimizations would deliver?<br /><br />2. Selftype. "This can be achieved today by manually overriding the method in each and every subclass. However that doesn't work if you want to add a new method to the abstract superclass in the future and have it picked up by every subclass (which is what you want in a JSR, as a JSR doesn't have a perfect crystal ball for its first release)."<br /><br />What's the point? If you're changing the superclass adding a method you're changing the API (I mean, there's no existing client calling that method), so where's the problem in adding the methods in subclasses? Adding manually a few lines to subclasses seriously disrupt the capacity of designing an API? :-)<br /><br />"Again, a language-level missing feature severely compromises a library-level JSR."<br /><br />So how people managed in designing the 309 JSRs prior Date Time? :-)Fabrizio Giudicihttp://weblogs.java.net/blog/fabriziogiudici/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-2941025761516044452007-10-07T20:05:33.000+01:002007-10-07T20:05:33.000+01:00You lost me, I don't understand the problem. W...You lost me, I don't understand the problem. What's wrong with representing a duration as an array of long amounts of milliseconds?<br /><br />Just because you want to have Days doesn't mean your internal representation has to be that. And who wants a decimal number of days?Torbjörn Gannholmnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-49298751806944474792007-10-06T19:20:36.000+01:002007-10-06T19:20:36.000+01:00Slava: you prefer to stuck with a language nobody...Slava: you prefer to stuck with a language nobody will ever use.afsinanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-82580492892101937512007-10-06T18:43:30.000+01:002007-10-06T18:43:30.000+01:00"On Scala, I think it has great potential, ho..."On Scala, I think it has great potential, however I hate that where they place the type (val surname : String). As a result its not my Java 3. "<br /><br />As long as you guys get hung up on trivial issues like this, you will always be stuck with crappy mainstream languages.Slava Pestovnoreply@blogger.com