Showing messages 1 through 29 of 29.

• Tiffany jewellery
  2009-07-02 02:02:52 luckey_001 [Reply | View]
  
  You will find the great selection of Tiffany Jewellery at Tiffanys jewellery online store. Tiffanys jewellery is your best Links of London Silver jewelry online store.Tiffany & Co jewelry is interantional famous brands.It had become legendary for a long time because of the movie- BREAKFAST AT TIFFANY (1961) and Audrey Hepburn. Linksoflondon provides the best Tiffany & Co jewelry. Moreover, the Links of London necklace are crafted with the quality of being beautiful and delicate in appearance, and they are inspected for a fineness mark to ensure quality.
  <hr>
  
  
  

• HmmDon't you think that there's some level of "pot calling kettle" with all this fanboy talk? I mean those against the idea are surely anti-closure fanboys so why don't we drop the name calling and insults and actually say something of meaning and su
  2008-08-22 03:54:03 sorrynoremorse [Reply | View]
  
  Don't you think that there's some level of "pot calling kettle" with all this fanboy talk? I mean those against the idea are surely anti-closure fanboys so why don't we drop the name calling and insults and actually say something of meaning and substance about the issue?
  
  Oh and anybody who wants to stop programming in Java if it gains closures I'm sure are more than welcome in .NET but I'd best warn you the closures are already there.
  
  IMHO, and that's all it is, a large number of people don't want closures for two big reasons: seemingly complex syntax, and being irritated by the generics introduction.
  
  To address the later first; if you feel that one feature of the language (which you are not obliged to use just turn off the warnings) that doesn't work for you is a good enough reason to spurn any further features of Java then so be it. The same was said about many of the PHP5 features but its still got a strong userbase. Nobody says you have to use closures if they're introduced have they? Say you don't like the Sun implementations of the Collections interfaces, you'd use something else right? Like the Apache commons stuff.
  
  Coming back to the syntax; if you don't understand it its probably because you've not read it properly. Sorry but its true, the syntax is nothing new with respect to lambda expressions and even bears a strong resemblence to C function pointer syntax. If you read, say, Neal Gafter's articles on the BGGA implementation I'd be very surprised if you couldn't then understand it AND more importantly why its formatted that way.
  
  Again IMHO if closures are to be included the debate about their implementation is either simple syntactic sugar for anonymous inner-classes OR a more flexible and powerful (should you wish to lever it) feature?
  
  I think if it were possible I'd like to see, as others have said, a longer period before the J7 release and a good amount of bug fixing and optimising in the current release.

• JSR for C#
  2008-08-13 16:52:37 mrmorris [Reply | View]
  
  How about we just create a JSR for getting C# running on the JVM? They have properties, events closures, no bloody checked exceptions and then Sun can have as much fun with JavaFX and other derailments as they want. :)
• JSR for C#
  2008-08-14 07:14:04 scotty69 [Reply | View]
  
  Sad but true. Something like LINQ would take years of controversy in Javaland.
• JSR for C#
  2008-08-14 01:57:09 imichtch [Reply | View]
  
  Greate idea!!! But off cause Sun prefers inventing own "perfect" wheel...
• JSR for C#
  2008-08-14 11:14:06 aehrenr [Reply | View]
  
  In my eyes C# is just another Perl 6 or C++.
  A language totally overloaded with features, most of them useless in the reality and without any good design.
  I think this is also the reason why more people use Java despite the huge amount of money Microsoft is investing in its cloned technology.
  The discussion about closures and if you want about properties is because many people that use Java in their everyday job do not want it to become distorted by features that only serve the vanity of few. A arms race of computer languages is goofy and not productive.
• JSR for C#
  2008-08-15 05:00:27 nopjn [Reply | View]
  
  Aren't properties and binding (like in JavaFX) go for productivity ?
• JSR for C#
  2008-08-15 22:54:10 aehrenr [Reply | View]
  
  This would have been true if properties (and closures) would have been present from the start.
  If you introduce them now you have parallel idioms for the same things everywhere.
  These features change basically the style of APIs you can not change them afterwards without producing a complete mess
• JSR for C#
  2008-08-15 05:20:38 nopjn [Reply | View]
  
  *good for productivity

• No answer
  2008-08-13 09:26:59 scolebourne [Reply | View]
  
  

  I can't really answer this (as the co-author of FCM closures). The problems involved are complex, and the practicalities of finding a suitable solution equally so. "Closures" has also come to mean many things in the debate, from simpler inner classes right up to full-featured Scala-like constructs.

  I should also emphasise that the debate isn't really about the syntax, but the semantics. Do last-line-no-semicolon return of values, and non-local returns have a place in Java? Is the extra power justified?

  My opinion is that the debate needs at least another 2-3 years of expert examination if the right answer is to be reached. If Java 7 will wait, then so be it. Personally, I would have preferred to have seen a Java 7 out this year with no language changes, followed by a Java 8 with such changes in about 2010. But unfortunately, Sun have taken their eye off the ball with the JavaFX misadventure.

• some thoughts
  2008-08-13 09:01:41 yardena [Reply | View]
  
  As much as I would like to see properties in Java, there is no JSR or even proposal which has enough community interest, so it is very unlikely. And that's a shame, because all the new binding and validation stuff is using Strings.
  
  As for closures BGGA syntax is only scary in the beginning, and it's easy to get used to. Closures come from functional programming and the syntax follows FP style - yes, it is not like anything in Java today because it's a new paradigm, so what?
  
  One thing I would want to be taken in account is this: hopefully Sun has not given up on generics reification in the future, and that would allow more type inference, how (or whether) would it affect the closure syntax? From my very modest understanding, BGGA would greatly benefit from reification/type inference, making the piece that spooks many Javans today ( => ) optional. But some real language expert should make sure the syntax is "forward compatible" with reified generics.
  
  So I say, give us BGGA closures, and those who are scared of the syntax will not use it until it is simplified in a later version. But bold libraries providers will benefit from it ASAP.

• some thoughts
  2008-08-13 08:46:39 yardena [Reply | View]
  
  As much as I would like to see properties in Java, there is no JSR or even proposal which has enough community interest, so it is very unlikely. And that's a shame, because all the new binding and validation stuff is using Strings.
  
  As for closures BGGA syntax is only scary in the beginning, and it's easy to get used to. Closures come from functional programming and the syntax follows FP style - yes, it is not like anything in Java today because it's a new paradigm, so what?
  
  One thing I would want to be taken in account is this: hopefully Sun has not given up on generics reification in the future, and that would allow more type inference, how (or whether) would it affect the closure syntax? From my very modest understanding, BGGA would greatly benefit from reification/type inference, making the piece that spooks many Javans today ( => ) optional. But some real language expert should make sure the syntax is "forward compatible" with reified generics.
  
  So I say, give us BGGA closures, and those who are scared of the syntax will not use it until it is simplified in a later version. But bold libraries providers will benefit from it ASAP.

• properties
  2008-08-13 03:41:11 nopjn [Reply | View]
  
  +1 for properties
  If my understanding is right, it will allow use easy binding, which is the main new feature of JavaFX Script (besides the other features :) )

• Ship it with Java 7 but take your time for Java 7
  2008-08-12 12:39:31 aehrenr [Reply | View]
  
  I think Java 7 should be shipped in 2 or three years time. Priority should be set on quality not on new features. Take your time to think about each and every language change included. Meanwhile Java 6 should see many bugfix releases.
  Quality is much more important than features !!!

• Yes to JDK7 with BGGA!
  2008-08-12 10:44:11 scotty69 [Reply | View]
  
  It's a new and exciting way of looking at many old and odd problems. And don't forget properties as first-class citizens ;-)

• Yes, pick BGGA, maybe slightly change a syntax and urgently ship it with Java 7.
  2008-08-11 23:02:30 andrein [Reply | View]
  
  Please, also ship other libraries like java.util.concurrent with closures functionality.

• Is now the time?
  2008-08-11 13:49:15 aberrant [Reply | View]
  
  Is now the time to debate syntax? People were getting a lot of flack for debating syntax when this was all just proposals. Now we have prototypes and "feature complete" implementations, is this the time?
  
  I find BGGA to be a very confusing syntax. It does a lot of things in an unintuitive way for no other reason then to just to be different.
  
  In java if something takes parameters and returns a value it's written like this:
  
  int valueOf(String s){
  ...
  };
  
  In BGGA a closure that takes the same signature is.
  
  {int => String s ....}
  
  It's the same signature so why isn't it even something close to the same syntax?
  
  in FCM you write the same thing like this:
  
  #int(String s){
  ...
  }
  
  Other then the # sign it's exactly like what you would do if writing a method.
  
  Whats with the "last line no semi-color means return" semantic? How is that expressive? Why can't I return early? Why introduce a place in the code where NOT putting a semi colon at the end of the line means something?
  
  I'm sure the answer is because then you'd have to use return keyword. Well I've used languages with no return keyword. VB 6 had no return keyword and you had to play all kinds of games to return the value you really wanted and break out of loops and things like that when things got complicated.
  
  BGGA is not the answer, it's just the one that's gotten the most attention. FCM+JCA is virtually the same functionality in a more Java-like package plus useful extras like field and constructor literals.
• Is now the time?
  2008-08-12 18:26:38 twosuns [Reply | View]
  
  I also think that the syntax is horrible... With that horrible syntax Java is RIP.

• Delay Java 7 if necessary
  2008-08-11 10:20:53 jhannes [Reply | View]
  
  The experience from generics show that a rushed process gives us too much complexity and too little power.
  
  Closures, done right, has the potential of extending the life span of Java with another fifteen good years. Done wrong, the complexity could be the hair that broke the camel's back.
  
  Rushing now means BGGA, which hardly anyone understands.
• Delay Java 7 if necessary
  2008-08-14 02:09:54 ewin [Reply | View]
  
  Generics weren't rushed. In fact, they were "discussed" for several years.

  The problems with this "discussion" were:

  • The decision to have generics was a done deal right from the beginning, with no way out to stop doing it when it turned out not to be a good idea (just like closures are a done deal since some time now, with no way out)
  • The discussion about the details of generics were done behind closed doors by the JCP clique (Sun didn't manage to keep the closure discussion as secret as the generics discussion, but I bet they regret it. The only reason closures see some public mentioning^(*) is because Sun's darling Mr. Neal Gafter went so much over the top (e.g. getting all support from Sun and showing t*tts to promote closures) that the rest of the JCP clique couldn't keep their mouth shut)
  • Generics were done by people who had no f*cking clue about the real world, real-world programming problems, and real-world programmer skills (just like it happens with closures now)
  • Much of what was published about generics before their introduction were blatant lies.Like how easy they are and how well they fit into Java. Like "the VM won't change", of course the VM was changed in the same release they introduced generics. Or like how badly generics were needed to reduce programming errors with collections. Strange that no real-world programmer (as opposite to college kids and language theory w*nkers) had problems with that. (same with closures today: problems are exaggerated to which closures allegedly need come to the rescue. Simplicity and "beauty" is claimed for every POS closure syntax)

  It doesn't matter if Java 7 will be delayed because of closures or not,. Sun will force-feed us closures. The number under which they will ram them in our mouth doesn't matter (anyhow, since when did Sun manage to keep product version numbers straight?).

  ---
  ^(*) I wrote "public mentioning" and not "public discussion" by intentions, because the closure fanboys aren't willing to discuss the no-closure option at all, instead they prefer living in their lalala land.
  

• Generics discussion was open
  2008-08-15 04:06:28 mthornton [Reply | View]
  
  There was plenty of open discussion of generics on the generics forum for years before it was added to Java. The problem was that many of the people who have later complained never bothered to look.
• But maybe we can prevent BGGA
  2008-08-14 11:57:43 aehrenr [Reply | View]
  
  I also think there is no way to stop closures. People are recently so fond of functional programming that they see it as a innovative smart concept. Despite the fact that it is no new concept and wasn't missed in the C languages. So in future we have function pointers in Java together with an additional idiom to formulate iterations. Java will die without this, all programs written with Java until now are just trifles.
  People supporting BGGA often think that Scala can become a mainstream language and this illustrates nicely how far from reality they are.
  So I think we must at least try to prevent BGGA closures in Java as they try to be the next 1000% solution, similar to the wildcards in the generics field.
  Generics would have been OK without them.
• Delay Java 7 if necessary
  2008-08-14 06:44:11 dserodio [Reply | View]
  
  

  ... the closure fanboys aren't willing to discuss the no-closure option at all, instead they prefer living in their lalala land

  
  Right on the target! Closures don't belong in Java, they belong in Groovy! Sun should support Groovy instead of turning Java into the proberbial kitchen sink....
  Too bad, I guess it's time to learn C#
• Delay Java 7 if necessary
  2008-08-11 11:04:12 gafter [Reply | View]
  
  If you don't understand BGGA, I recommend Zdenĕk Troníček's excellent tutorial linked from http://www.javac.info. There is also a feature-complete prototype that you can try.

• Consequences
  2008-08-08 09:27:23 markmahieu [Reply | View]
  
  If the decision on closures is delayed until after Java 7, then it's likely we'll see the following 80 or so interfaces added to the platform as a workaround:
  
  http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/jsr166y/forkjoin/Ops.html
  
  Although those interfaces have clearly been put together with care and pragmatism, they are a compromise, and Java developers who need to make use of the excellent fork/join framework are going to have to put up with code that's more difficult to write, to understand and to maintain than it should be. Not good when you're dealing with something as tricky as concurrency, and if Intel, Microsoft, Sun et al are correct about the implications of multi-core on how we write software, that's likely to be an awful lot of us going forward.
  
  Unfortunately, such workarounds have a nasty habit of becoming de facto standards.
• Consequences
  2008-08-15 03:41:01 mthornton [Reply | View]
  
  Extending generics to primitives would also substantially reduce the number of interfaces required by the fork join proposal. Most of those 80 interfaces are just the result of enumerating different combinations of object and primitive parameters.
  
  As performance is crucial to fork/join ( you wouldn't use it at all if performance didn't matter), it isn't possible to eliminate the use of primitives.
• Consequences
  2008-08-12 01:57:47 jwenting [Reply | View]
  
  The decision should be made NOW to scrap the entire "closures" idiocy completely. There's no need for function pointers (and that's what they essentially are) in Java. All they do is make the language syntax far more obscure and obfuscated, which serves noone except for stroking the vanity of the person(s) whose proposal gets implemented for a while (until the negative consequences of the adapting of their idea become apparent to all that is, after that they'll just have notoriety).

  Maybe it's time to hand over the language spec to the ISO/ECMA, at least they spend decades debating such decisions, making them both well thought out and late enough that my career would be over before they ever make it into the mainstream, rather than making them based on a Me2! mentality as is the case with everything Sun and the JCP are doing these days.

• Consequences
  2008-08-14 02:18:49 ewin [Reply | View]
  
  

  The decision should be made NOW to scrap the entire "closures" idiocy completely.

  But long time ago Sun made a final decision that Java needs to have closures. That's why the closure fanboys can afford to ignore all arguments. They know they don't have to listen.

  It is not a question if closures or not, but just which POS syntax and POS semantics we will get.

  Closures are about the careers of those who promote them (e.g. landing a job at Google). They are not about the language, and certainly not about Joe Average Programmer.

• Consequences
  2008-08-14 06:51:22 dserodio [Reply | View]
  
  I second every word of your post.
  
  I don't understand why Sun doesn't invest more in Groovy! Closures are a natural fit in Groovy, but seem shoehorned in Java! I think Java is embracing Perl's "There's more than one way to do it" motto!