If a principle doesn't have a wikipedia page, it doesn't exist :)
Seriously for a moment: Tossing the names of old programming language
codgers about is an effective way to close off all discussion with
your average non-language nut. The principle is simple enough, why do
we have to complicate it
John:
The use case is writing your own language features.
Imagine we had a long return closure system.
Then 'foreach' is utterly unneccessary. You could just write it as a
library. Same story for ARM-like proposals (File.doForEachLine),
functional style collections operations, such as filter, f
Ah, but, screwing around with the meanings of method signatures would
make some serious backwards incompatibility issues.
Fortunately class files have version info so you could do some trick
whereby new class files do set a difference, but if an old class file
code wants to acess a new class file
Ben,
Tennent's Correspondence Principle means that you always can create a
function that can replace an expression and it always means the same
thing. You know what, Java is not a functional language, and it never
will be...
I think that if you make references to a theoretical principle from
198
Heh? Breaking out of/returning from within loops, I thought that's
what's being discussed??
Reinier: The second difference should be that "CICE violates Tennent's
Correspondence Principle while BGGA does not." That is not only more
concise, it is also more accurate.
With kind regards
Ben
On 15
On Fri, Jan 16, 2009 at 3:17 AM, Tom Hawtin wrote:
>
> On Jan 14, 3:28 pm, Reinier Zwitserloot wrote:
>
>> com.package.ContainingClass.foobar(Ljava/util/List;V)
>> com.package.ContainingClass.foobar(Ljava/util/List;I)
>>
>> which is not okay - being only different in return type is not
>> allowe
OK, so it's not news exactly but it is a nice mention:
http://www.artima.com/weblogs/viewpost.jsp?thread=247472
Dave
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, sen
That's great hari, thanks for the links!
From: javaposse@googlegroups.com [mailto:javapo...@googlegroups.com] On
Behalf Of hari jayaram
Sent: Thursday, January 15, 2009 9:25 AM
To: javaposse@googlegroups.com
Subject: [The Java Posse] Jared diamond book-
Hi
Hi , I listen to the podcast regularly since I use java in my structural
biology research.
I heard you guys talking about Jared diamonds book Guns germs and Steel and
I am taking the liberty of sending along a link to an amazing talk that
Jared Diamond gave at the seminars for the longnow founda
Actually, what is the use case for long returns? What would you like to do
with it?
The examples I can come up with is better solved with tail recursion...
BR,
John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Th
On Jan 14, 3:28 pm, Reinier Zwitserloot wrote:
> com.package.ContainingClass.foobar(Ljava/util/List;V)
> com.package.ContainingClass.foobar(Ljava/util/List;I)
>
> which is not okay - being only different in return type is not
> allowed. This isn't a big concern and is not generally covered by wh
On Jan 14, 10:13 pm, David wrote:
> Now that QT has been offered as both GPL and LGPL I was wondering if
> there has been any thought of rolling it into Java.
Rolling it into OpenJDK and exposing it as yet another built-in GUI
API seems
unnecessary to me, given that Qt Jambi exists.
The use of
Not that bad, perhaps, but it still means we must have context
sensitive keywords before that is going to be possible (and in
general, I say, avoid those like the plague). It's also still
ambiguous, just less so: return (5); is perfectly legal today. Just
virtually never used.
Also, it's still no
13 matches
Mail list logo
