On Tue, Sep 1, 2009 at 5:44 PM, Mark Derricutt m...@talios.com wrote:
I've always been intrigued by these blocks we have in java, what does javac
actually generate for them?
Not much. It just reuses slots. But don't take my word for it
~/test$ cat Test.java
public class Test {
public
For various practical reasons it's usually better to not define fields in
Scala traits, but Scala does allow it
scala trait Foo { var x = 42 }
defined trait Foo
scala class Bar extends Foo
defined class Bar
scala val b = new Bar
b: Bar = b...@8be1c9
scala b.x
res2: Int = 42
scala b.x = 13
On Wed, Aug 19, 2009 at 11:45 AM, Reinier Zwitserloot reini...@gmail.comwrote:
disjoint types are structural in that you weaken the namespacing of
members.
Disjoint types aren't structural unless the language makes them so. Java
could be extended with disjoint types that compute a least
Exactly. The Camera/Gun argument against structural typing doesn't hold
water because the programmer's error is exactly the same semantic problem as
// my library
interface Camera {
void shoot();
}
// somebody else's code
class Bazooka extends Camera {...}
The only constraints that Java
On Wed, Aug 19, 2009 at 1:03 AM, Peter Becker peter.becker...@gmail.comwrote:
Interestingly Java's generics allow the dual construction on interfaces:
public T extends Interface1 Interface2 void someMethod(T param) {...}
Yeah, you can do intersection types in generics. But you can't write
I don't follow. Union types don't seem particularly structural to me.
They're the disjunction of other types, and if the other types are
nominative then so is the union of them. A type like String | Integer
contians all expressions that are Strings or Integers. The idea would be
that you can
On Wed, Aug 19, 2009 at 7:36 AM, Ben Schulz ya...@gmx.net wrote:
don't feel like you gained much in your sample, you could just replace
String | Integer with Object and add a default: throw new
AssertionError();. Obviously you gained type safety,
Isn't that kinda the point of a type
On Tue, Aug 18, 2009 at 3:13 AM, Peter Becker peter.becker...@gmail.comwrote:
What I would really like to see is a meet/or/disjunction/union operator
in the type system, with a case-like construct to resolve the resulting
types. Scala has two things that are halfway there (Either, case
I really hate phrasing something like this as being a figment. That's
like saying that short and char are figments of the JVM's imagination
because it's all just bits.
None-the-less, the answer is that checked exceptions are enforced by Java's
static system and not by the JVM at all. So Scala,
On Tue, Aug 18, 2009 at 7:11 PM, Casper Bang casper.b...@gmail.com wrote:
Yeah well, it depends how you look at it I suppose. I would also claim
generics to be a figment of the JVM's imagination, since you can not
implement ComparableInteger and ComparableBigInteger due to it
being an
We give programmers great flexibility in naming things. Programmers can and
do misname things. Smart teams use guidelines, mentoring, code reviews, and
refactoring to prevent, detect, and fix misnaming problems. Operator
overloading does not fundamentally change the nature of the problem or its
http://www.jroller.com/scolebourne/entry/no_more_java_7
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this
On Mon, Mar 23, 2009 at 3:06 PM, Casper Bang casper.b...@gmail.com wrote:
These aspect has probably been
most prominently covered by Paul Graham's essays Java's cover,
Great hackers and Hackers and Painters:
The funny thing about Java's cover essay is how right he is about Java's
cover but
Yes, tuples are ordered. (foo,bar) is not the same as (bar, foo).
One way to think of tuples is as records or structures where the name given
to each field is it's position in the tuple. So the first tuple is (1 =
foo, 2 = bar) while the second is (1 = bar, 2 = foo)
To answer your other question
If you just want multiple return/assignment there are quite a few ways
to deal with the problem. One common way is to try to just push
multiple values on the stack. But I think the design of the current
JVM pretty much limits you to using TupleN classes, a list structure,
or arrays. Still,
On Feb 13, 6:10 am, Robert Fischer robert.fisc...@smokejumperit.com
wrote:
Why does it have to be Clojure *or* Scala? While Clojure no doubt has
theoretical purity on its
side,
Clojure doesn't have any theoretical purity. A theoretician will tell
you that it's an impure functional
On Feb 13, 8:51 pm, Ed edwilson...@gmail.com wrote:
Because (besides domain specific languages) this world cannot deal
with more than one language at a time. In the 70's it was C, the 80's
it was [hold on to your keyboards] C++, then Java, now the world is
thinking if C# only ran on
Scala doesn't work that way because Tuples have O(1) access to all
elements where what you propose would have O(n) access. Having 22
Tuple classes is definitely a code smell. Same with having 22
Function classes. But those are code smells forced by the JVM. On
machines with a less strict
interface ParentT extends ParentT extends IterableT {
}
interface ChildT extends ChildT extends ParentT {
}
class ParentImpl implements ParentParentImpl {
public IteratorParentImpl iterator() {
ListParentImpl list = new
I don't think what you want to express can be expressed in Java
because Iterable is invariant - an IterableChild isn't a subtype of
IterableParent. Nor can you write interface Parent extends
Iterable? extends Parent
It can be expressed in Scala, but not with Java's standard Iterator/
Iterable
On Jan 27, 4:23 pm, Reinier Zwitserloot reini...@gmail.com wrote:
They didn't bollocks up generics at all. They are fine as is.
Here are some things that IMHO would have made generics much better
without breaking backwards compatibility. I think call of these could
still be done, in fact.
On Jan 27, 7:34 pm, Christian Catchpole christ...@catchpole.net
wrote:
When generics first came along I thought 'great, no more casting'. So
I disassembled some source, only to find that casts still do exist
after the caller calls a generified method. This is because generics
can still
I listed a few alternatives in another email - not that I think they
are appropriate for Java, but they are alternatives.
1) C++ style compile time polyinstantiation
2) .Net style runtime polyinstantiation, but more extensively
than .Net does it.
In either case, ArrayListString would generate
Turn about is fair play:
http://james-iry.blogspot.com/2009/01/by-reading-joel-fog-you-will-be-able-to.html
On Jan 13, 12:25 am, Dominic Mitchell d...@happygiraffe.net wrote:
Joel is quite accurate. :)
http://www.joelonsoftware.com/items/2009/01/12.html
-Dom
-man
approach that you mentioned?
Thanks all for the help so far, I also think i'll be joining that
google-group too!
Cheers,
Mark
On Jan 9, 1:03 am, James Iry james...@gmail.com wrote:
I'm a little late to this conversation.
For some reason, all the responses have been about parsing
It's not FUD, exactly.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=groovylang2=java
But hideous is a judgement call that depends on your needs. For the
kinds of problems for which dynamic scripting languages are well
suited performance is usually a secondary concern. And
There are a couple of problems with that code far as generic reuse is
concerned. First, calling code must know what kind of target
collection it wants before calling map. The higher kinded solution
allows calling code to remain generic and oblivious to what is being
mapped. If the calling
On Dec 28, 11:42 am, Robert Lally rob.la...@gmail.com wrote:
That's where I'd have to disagree with you a little. When I'm reading
someone else's code (or even my own code I wrote a few months ago), I want
to be able to understand at a glance what the author was trying to do. The
code
Tony's um...debating style shouldn't be taken as reflecting the Scala
community in general.
To the topic at hand: Scala has only a few things are are genuinely
foreign to Java programmers. For instance, except for non-local
return, Scala's lambdas are really just a shortcut to writing certain
On Dec 27, 6:11 pm, Robert Lally rob.la...@gmail.com wrote:
Tony has operator privileges on #scala,
That's because, AFAIK, he started that channel.
With this, he is a significant and
influential member of the Scala community and sets the tone for much of the
IRC conversation. Feel free
Hi John,
Thanks for investigating rather than taking such claims on face
value. Indeed, the Scala language is compatible with Java's List
hierarchy. As you point out, scala.List is just another class which
you can use or not use.
There is one caveat that brings a small kernel of truth to the
you are and ignore him. I don't like being
called stupid.
On Dec 24, 9:33 am, James Iry james...@gmail.com wrote:
Hi John,
Thanks for investigating rather than taking such claims on face
value. Indeed, the Scala language is compatible with Java's List
hierarchy. As you point out
On Dec 23, 7:39 am, Reinier Zwitserloot reini...@gmail.com wrote:
This really isn't too hard. C is a light syntax sugar over standard
assembly. Haskell isn't anything like it.
First, that's not true in spite of everybody saying it. C, for
instance, imposes a strict regime about the stack
On Dec 22, 3:53 pm, Reinier Zwitserloot reini...@gmail.com wrote:
One thing about fan (and about scala, incidentally) that bugs me to no
end is the insistence of being both JVM and .NET compatible.
Why?
Because of this, Fan (and scala) have to re-invent everything, every
library that
On Dec 21, 1:51 am, Mark Derricutt m...@talios.com wrote:
_(Scala ! Shiny)
I remember much the same arguments about Java when it was first on the
public radar. Before that I remember C++ and OO in general getting
the same arguments. Before my time there were arguments about
structured vs
On Dec 21, 12:29 pm, Jan Goyvaerts java.arti...@gmail.com wrote:
It's the simplified syntax then... This is certainly nice to quickly create
a hierarchy of DTO classes. The problem though is that this kind of
declaration doesn't allow for additional properties/methods to be defined in
the
On Dec 21, 1:42 pm, Reinier Zwitserloot reini...@gmail.com wrote:
Anyone who knows both C++ and Java knows that the languages are in
fact not even in the same city, let alone the same ballpark.
As compared to Mercury and Haskell and Piet, C++ and Java are nearly
the same language :-)
On Dec 20, 4:47 am, peter peter_kova...@hotmail.com wrote:
the companies you are talking about are conservative by nature (for
example: financial institutions), I do not think any language (or even
On Dec 20, 3:17 am, Reinier Zwitserloot reini...@gmail.com wrote:
Except 'length' is much more descriptive, and /: and \: are aliases
for foldLeft / foldRight (a more appropriate simile would be that
Yes, but your objection was that you couldn't avoid /: and :\ because
they were always
80% ? The site says they cover List, Map, and Func(function).
Now, there are a lot of containers in the world like heaps, binary
trees, n-ary trees, queues, vectors, mactrices, and stacks, just to
name a few. Even in lists there are array based lists, linked lists,
skip lists, etc, etc. Plus,
On Dec 19, 3:39 pm, Reinier Zwitserloot reini...@gmail.com wrote:
Then you've got python, ruby, groovy, haskell, lisp, lua, fan and many more to
compete with
haskell, lisp, lua, fan and many more to compete with. If scala is
going to grow into something big, it either has to be so amazingly
On Dec 17, 3:14 am, Reinier Zwitserloot reini...@gmail.com wrote:
I don't think it's up to me to -prove- scala's problems here, as
proving it would take a few man-weeks- of work. Call it personal
No, but it would be enlightening to the rest of us to see a sample bit
of code and the error
42 matches
Mail list logo
