On Thu, May 7, 2009 at 6:20 PM, Reinier Zwitserloot <[email protected]>wrote:

>
> On May 7, 10:25 pm, Josh Suereth <[email protected]> wrote:
> > What's a good API to choose?  What will be sufficient?
>
> the new File API, the old File API, or the google collections API, for
> example.
>
> Here's a fun one, a java JSON API written towards being easy to use,
> and readable, in java code:
>
>
> JSON json = JSON.parse("{foo: 25, bar: [1, 2, 3]});
> double x = json.get("foo").asDouble(0.0);
> for ( JSON element : json.get("foo").get("bar").asList() ) {
>    int y = element.asInt();
> }
>


Imagining this API used in scala:

val json = JSON.parse("""{
   foo: 25,
   bar: [1, 2, 3]
}""");

val x = json("foo").asDouble(0.0)

for ( element <- json("foo")("bar").asList ) {
    val y = element.asInt
}


This assumes you create a JSON wrapper somewhat like so:

implicit def wrapJson(json : JSON) = new {
    def apply(slotName : String) = json.get(slotName)
}

or, just place the desired methods into the JSON object to begin with.  In
this instance, your lirbary does only add 30% syntax noise.

However, imagine the JSON parser itself.  See here for a scala
implementation <http://www.hvergi.net/2008/06/parsing-json-with-scala/>.
Now, you are right, I could spend a lot of time making this same thing
possible, and less verbose in Java.   However, in the course of a day, I'd
rather spend my time adding value to the business.  If I can create a highly
valueable API in scala in less time, I will do so.  I'd like to see the JSON
parsing implementation that goes behind this API.   Like I said, there are
some APIs that are well expressed in Java.   However, there are some APIs
that are not.

Also, Imagine parsing more lists in your JSON and trying to return values:

val json = JSON.parse("""{
   foo: 25,
   bar: [{
       baz: 25
       faz: [ 10, 21, 34, 12 ]
   }]
}""");


//Asume JSON object has an "isArray" method
val results = for {
   barItem <- json("bar").asList
   fazItem <- barItem("faz").asList
   if fazItem.asDouble(0.0) > 30.0
} yield fazItem

for( result <- result ) {   System.out.println(result); }

//This would Print "34"


Now the Java:


List<Double> results = new ArrayList<Double>();
for ( JSON element : json.get("bar").asList() ) {
   for(JSON element2 : element.get("faz").asList()) {
           double value = element2.asDouble(0.0)
           if(value > 30.0) {
               results.add(value);
           }
   }
}

for(double result : results) {
       System.out.println(result);
}

As you can see, with more and more internal lists, the java begins to look
worse and worse, but the Scala remains somewhat linear in readability.


In terms of file APIs, let's compare actor based APIs (java's Killim, vs.
Scala's core library)


import kilim.*;

interface MsgType extends Serializable {}
//Class Hierarchy defined


class Mbx extends Mailbox<MsgType> {}

class MyActor extends Actor {
   Mbx mb;
   MyActor(Mbx mb) { this.mb = mb }

 @pausable
 public void execute() {
   while(true) {
     MsgType m = mb.get();
     if(m instanceOf Foo) {
           handleFoo((Foo)m);
     } else if(m instanceOf Bar) {
           handleBar((Bar)m);
     }
     reply(m);
  }}
  public void handleFoo(Foo foo) { ... }
  public void handleBar(Bar bar) { ... }
}


// spawn actor
Mbx outmb = new Mbx();
new MyActor(outmb).start();

outmb.put(new Foo(foodata));



=== Scala ===

@Serializable
sealed trait MsgType
// Define class hierarchy


import actors.Actor._
val myActor = actor {
    loopWhile(true) {
         react {
               case foo : Foo => ...
               case bar : Bar => ...
         }
    }
}

myActor.send( new Foo(foodata) )  // Could also use myActor ! new
Foo(foodata)

In both examples I see Scala as having less noise.  Also note that Scala's
example does not require any bytecode rewritting magic or reflection to
happen for it to work correctly.  Also note, that for complex "should we
handle this message properly", scala lets you abstract out "Extractor"
objects to keep the "case foo => " statements simple, while adding some
re-usability.  The java equivalent is not nearly as nice.


Finally, when I talked about Java, I should say it's the "C" of the JVM.
It plays the role of being closest to the bytecode (without actually being
bytecode) and therefore would always have a place behind slower language
implementations.  Look at a lot of PERL APIs, even Ruby and Python.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to