On Tue, Sep 1, 2009 at 5:44 PM, Mark Derricutt 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 void test() {
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
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 can
On Wed, Aug 19, 2009 at 11:45 AM, Reinier Zwitserloot wrote:
>
> 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 upper bound
nomin
C style error codes suck because they're too easy to forget to check (by the
way, null is a lot like a C style error code because it extends the normal
domain of a result invisibly, so it sucks too).
But to be fair Joel also talked about the ML/Haskell(/Scala/F#/etc) style of
returning an algebrai
On Wed, Aug 19, 2009 at 7:36 AM, Ben Schulz 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 system? :-
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 writ
On Wed, Aug 19, 2009 at 1:03 AM, Peter Becker wrote:
>
> Interestingly Java's generics allow the dual construction on interfaces:
>
> public void someMethod(T param) {...}
Yeah, you can do intersection types in generics. But you can't write
Interface1 & Interface2 foo() {...}
Interface1 & In
On Tue, Aug 18, 2009 at 7:11 PM, Casper Bang 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 Comparable and Comparable due to it
> being an emulated construct at the parser level.
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 Sc
On Tue, Aug 18, 2009 at 3:13 AM, Peter Becker wrote:
>
> 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
> classes), but neither is t
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 thi
On Mon, Mar 23, 2009 at 3:06 PM, Casper Bang 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 how wron
Coincidentally, lift, a web application framework for Scala, reached its 1.0
milestone this week: http://www.msnbc.msn.com/id/29412201/
The end is nigh.
On Sun, Mar 1, 2009 at 11:18 PM, Alotor wrote:
>
> Anyway, i hope that the fuzz this may provoke don't transform Scala in
> the new RoR.
>
>
-
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
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, there
On Feb 13, 8:51 pm, Ed 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 *nix/Mac and variants w
On Feb 13, 6:10 am, Robert Fischer
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 language in that you can have
arbitr
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 sta
I don't think what you want to express can be expressed in Java
because Iterable is invariant - an Iterable isn't a subtype of
Iterable. Nor can you write "interface Parent extends
Iterable"
It can be expressed in Scala, but not with Java's standard Iterator/
Iterable because they aren't covaria
interface Parent> extends Iterable {
}
interface Child> extends Parent {
}
class ParentImpl implements Parent {
public Iterator iterator() {
List list = new ArrayList();
list.add(new ParentImpl());
re
On Jan 28, 5:10 pm, Reinier Zwitserloot wrote:
> Ben, James:
>
> but about the ability to declare an
> entire type array-style subtypable in a pinch.
Except that Java's array covariance isn't statically type safe, and
except that we also want contravariance, yes you have the idea. But
not "in
On Jan 28, 1:34 pm, Reinier Zwitserloot wrote:
>
> How would this work? I don't think the scala strategy (cartoon
> swearing instead of 'extends' and 'super' keywords) is viable.
That's focusing too much on syntax. Use keywords. I don't care.
Whatever. C# 4 is stealing Scala's definition s
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, ArrayList would generate it's own
On Jan 27, 7:34 pm, Christian Catchpole
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 be subverted with c
On Jan 27, 7:18 pm, Reinier Zwitserloot wrote:
> It's hard in scala, too, and that has reification).
Scala's type parameters are erased in just the same way as Java's.
Scala needs to retain compatibility so we're stuck with erasure.
Or are you talking about the experiment, unsupported, and l
On Jan 27, 4:23 pm, Reinier Zwitserloot 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.
1) Optional defini
Actually, you can repair CICE in terms of TCP by appealing to fairly
ordinary lexical scoping rules. The idea is that you say that return
is a one-shot continuation that is implicitly received by any method
or function. Thus lambdas mask the meaning of "return" in their
enclosing scope because t
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 wrote:
> Joel is quite accurate. :)
>
> http://www.joelonsoftware.com/items/2009/01/12.html
>
> -Dom
--~--~-~--~~~---~--
ould you please explain a little more on the "lazy-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 wrote:
>
> > I
I'm not aware of any better books than TAPL for covering what it
covers. But it's a pretty deep dive into type systems, not something
I would recommend for somebody who just wants to get his feet wet in
building languages. I haven't read EoPL, but since I'm quite fond of
Scheme I don't think I w
It's not FUD, exactly.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=groovy&lang2=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. A
I'm a little late to this conversation.
For some reason, all the responses have been about parsing. Parsing
is the easiest problem related to languages - a zillion man hours of
research have made it a "solved" problem. ANTLR, Rats, Scala's parser
combinators, whatever. There are reasons to pre
On Dec 28, 11:42 am, "Robert Lally" 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 should scream out
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 code
On Dec 27, 6:11 pm, "Robert Lally" 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 to insert you
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
ki
Oops, my sock puppet was busted. :-)
On Dec 24, 10:31 am, James Iry wrote:
> Yeah if scala.List is differnt from java.util.List means that Scala is
> incompatible with Java then Java is incompatible with itself because
> it has java.util.List and java.awt.List also it has java.util
pid.
I'm going to do like you are and ignore him. I don't like being
called stupid.
On Dec 24, 9:33 am, James Iry wrote:
> Hi John,
>
> Thanks for investigating rather than taking such claims on face
> value. Indeed, the Scala language is compatible with Java's Lis
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
o
On Dec 23, 7:39 am, Reinier Zwitserloot 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 that assembly
doesn'
On Dec 22, 3:53 pm, Reinier Zwitserloot 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 ships with ja
On Dec 22, 4:11 pm, Reinier Zwitserloot wrote:
> In other regards, haskell and java have far more in common than C++
> and java. Running on a VM is a big one.
You just make stuff up, right? The Haskell spec says nothing about
running on a VM and GHC Haskell, the de facto standard, emits machin
On Dec 21, 1:42 pm, Reinier Zwitserloot 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 :-)
> giving up and adding
On Dec 21, 12:29 pm, "Jan Goyvaerts" 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 subclasses. Or does
On Dec 21, 1:51 am, "Mark Derricutt" 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 unstructured pr
On Dec 21, 5:58 am, "John Nilsson" wrote:
> I was just about to ask you when a tuple would be better than a class.
I can answer that question by drawing a parallel. When you write a
method in Java, you have a range of options for its arguments.
At one end of the range is
public void foo(Typ
First let me say that when I use Scala, what I miss from Java is the
richness of the tool support. Also, Scala has some limitations in the
kinds of annotations it can do. But that's about it, and both are
being worked on actively.
What I like in Scala over Java, in no particular order:
Type in
On Dec 20, 11:42 am, "phil.swen...@gmail.com"
wrote:
> I believe the fan containers can be most of the standard data-
> structures, like you list out.
But as soon as you wrap their generic List with say a Queue interface
and implement a heap based priority queue you lose genericness.
Enqueue
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 20, 3:17 am, Reinier Zwitserloot 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 there." My counter
On Dec 20, 4:47 am, peter wrote:
> the companies you are talking about are conservative by nature (for
> example: financial institutions), I do not think any language (or even
http://www.nabble.com/-scala--Scala-job-in-Boston-writing-quantitative-finance-software-tt20780369.html
Also Jane Stre
On Dec 19, 3:39 pm, Reinier Zwitserloot 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
> incredible it c
On Dec 17, 3:14 am, Reinier Zwitserloot 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 message that you thi
55 matches
Mail list logo
