Mahasooq | 1 Mar 09:35 2011
Picon

How to parse large XML files using vtd-xml library in Scala

Does anyone know how to parse large XML files using Xpath using vtd-
xml library in Scala.?

Marcus Downing | 1 Mar 09:57 2011
Picon

Re: Scala Object Notation ( SCON? )

As with JSON, there is the risk that what you think is simply a data format could be used to carry a payload of executing code. Modern JSON libraries and best practices attempt to prevent the execution of arbitrary Javascript within JSON. How would you achieve something similar with this format?
Mads Hartmann | 1 Mar 15:01 2011
Picon

Question regarding getting inspiration from the Scala Collections Library

Hi 


I'm not sure if this is the correct place to post a question like this so please correct me if I'm wrong. 


For my bachelors project at the IT University of Copenhagen I'm writing an immutable collections library for

javascript under the supervision of Peter Sestoft. 


Seeing that I'm coming from a Scala background I've adopted the use of Option and many of the names of 

the methods on the abstract data types like map, flatMap, filter, forEach (though camel-cased) and more. 


Is it enough to state this fact in the beginning of my report or do I need to include anything else in the code? 


Thanks,

Mads Hartmann Jensen

Noel Welsh | 1 Mar 16:05 2011

Re: Question regarding getting inspiration from the Scala Collections Library

In terms of giving credit, I think it is sufficient to state this in
your report. The Option type and the function names are common to
functional programming. You'll find the same things in Haskell etc.

N.

On Tue, Mar 1, 2011 at 2:01 PM, Mads Hartmann <mads379 <at> gmail.com> wrote:
> Hi
>
> I'm not sure if this is the correct place to post a question like this so
> please correct me if I'm wrong.
>
> For my bachelors project at the IT University of Copenhagen I'm writing an
> immutable collections library for
>
> javascript under the supervision of Peter Sestoft.
>
> Seeing that I'm coming from a Scala background I've adopted the use of
> Option and many of the names of
>
> the methods on the abstract data types like map, flatMap, filter, forEach
> (though camel-cased) and more.
>
> Is it enough to state this fact in the beginning of my report or do I need
> to include anything else in the code?
>
> Thanks,
>
> Mads Hartmann Jensen

--

-- 
Noel Welsh
Untyped Ltd                 http://www.untyped.com/
UK company number    06226466

Marcus Downing | 1 Mar 17:42 2011
Picon

Re: Question regarding getting inspiration from the Scala Collections Library

If you show evidence of having looked at - and stolen from - lots of different sources rather than one, it sounds better. So mention other immutable collection libraries that have similar named and types, and compare their good and bad points.

dontcare | 1 Mar 22:44 2011
Picon

[ANN]VTD-XML 2.10

VTD-XML 2.10 is now released in Java, C#, C and C++. It can be
downloaded at
https://sourceforge.net/projects/vtd-xml/files/vtd-xml/ximpleware_2.10/.
This release includes a number of new features and enhancement.

* The core API of VTD-XML has been expanded. Users can now perform
cut/paste/insert on an empty element.
* This release also adds the support of deeper location cache support
for parsing and indexing. This feature is useful for application
performance  tuning for processing various XML documents.
* The java version also added support for processing zip and gzip
files. Direct processing of httpURL based XML is enhanced.
* Extended Java version now support Iso-8859-10~16 encoding.
* A full featured C++ port is released.
* C version of VTD-XML now make use of thread local storage to achieve
thread safety for multi-threaded application.
* There are also a number of bugs fixed. Special thanks to Jozef
Aerts, John Sillers, Chris Tornau and a number of other users for
input and suggestions

Daniel Dekany | 2 Mar 14:21 2011
Picon

Supporting "builders" without boilerplate? [Was: var/val members aren't powerful enough to implement the "property" concept]

Sunday, February 27, 2011, 2:05:14 PM, Kevin Wright wrote:

> Certain forms of factory pattern are very well supported in Scala. 
> Using `apply` on a companion-object is practically canon for
> example, even being used in compiler-generated code for case classes.
>
> Using a factory class/object doesn't come with any syntactic sugar
> though - not that it's especially hard to write.

One doesn't have to be very intelligent to do that for sure, since
it's all just boilerplate. But that's also why it could be taken over
by the compiler (by some standard annotation maybe, or something
deeper).

> Either way though, it's worth noting that for any non-trivial
> example you'll be validating a combination of values, not just one
> "property" at a time.

Of course. Plus you have the a very similar problem with checking if a
required "property" was set.

> Given that isolated property validation will only be useful in very
> trivial examples, it seems even harder to justify the extra
> maintenance cost that it would add to the language and compiler.

While in reality you usually have validations that can only be done
after all properties were set, there still also will be many that can
be done right when the property is set, and the closest these
exception are raised to the cause is the better. But if putting all
the validations into a single method keeps the language
(significantly) simpler, it's certainly fine. So should then this
builder approach be better supported in Scala? If it should be, then
before going into anything else, exactly what should it give a
shorthand for? Here is my quick idea:

  class FooServer(val port: Int, val password: String) {
    // Validate here
  }

Imagine that it has dozens of parameters of course. When you don't
need all the builder bloat, you could just create a FooServer as:

  new FooServer(port = 80, password = "qweqwe")

Scala can do this already. But if you need a builder too (for coop
with Java, or because you need to set up the FooServer step-by-step in
Scala) then assuming you already have:

  abstract class Builder[A <: AnyRef] {
    def build(): A
  }

you had to write a builder like:

  class FooServerBuilder extends Builder[FooServer] {
    var port: Int = _
    var password: String = _

    def build() = new FooServer(port = port, password = password)
  }

which is a all just boring boilerplate. (It's repeating the same
things over and over. Relatively to what's already there in FooServer,
it repeats the parameter names three times more, the parameter types
once more, and the product class name twice more. And these all must
be kept in sync. And must not be miss-copy-pasted on the first place.)

Plus to support Spring,  <at> BeanProperty has to be added before each
`var`, and also you had to be able to chose a custom super-class
instead of Builder[A], like BuilderBasedFactoryBean[A]:

  import org.springframework.beans.factory.{InitializingBean, FactoryBean}

  abstract class BuilderBasedFactoryBean[A <: AnyRef](implicit m: Manifest[A])
      extends Builder[A] with FactoryBean[A] with InitializingBean {
    private var product: A = _

    // Spring InitializingBean methods:
    def afterPropertiesSet() {
      product = build()
    }

    // Spring FactoryBean methods:
    def getObject = product
    def isSingleton = true
    def getObjectType = m.erasure
  }

  /* Yeah, it's bit ugly because now the builder object is a holder for a
   * product object while independently of that it can create new objects
   * with build()... but it's practically good enough. */

Would this be a good approach? Worths supporting it in the language,
even if only with a standard annotation? Or is there some other
approach with similar results that would fit Scala better?

There is a few trickier cases regarding this, that I didn't dive into
yet, like:

(a) Default parameter:

  class FooServer(val port: Int = 80, val password: String) {
    // Validate here...
  }

then the builder had to be like:

  class FooServerBuilder ... {
    var port: Int = 80
    ...
  }

This can be tricky as the default expression was ripped out of its
original context. (Specifying the default only in the builder is not
very good, because then you must use a builder, and sometimes simply
calling the constructor fits more.)

(b) Inheritance:

If FooServer extends BarServer, and BarServer has a builder, then does
FooServerBuilder extends BarServerBuilder? Certainly yes. But I
haven't considered the consequences yet.

(c) What's if the preferred way of creating the instances without
builder is using apply on the companion object, rather than the
constructor. I don't think it's a big deal, just noted that it should
be possible.

--

-- 
Best regards,
 Daniel Dekany

Mads Hartmann Jensen | 2 Mar 16:50 2011
Picon

Re: Question regarding getting inspiration from the Scala Collections Library

Okay, thanks for the response guys. 

Mads

Kevin Wright | 2 Mar 19:30 2011
Picon

Re: Supporting "builders" without boilerplate? [Was: var/val members aren't powerful enough to implement the "property" concept]

There's a beautiful little trick that you can do, subverting setter methods to look like named params.

Outlined briefly here: http://stackoverflow.com/questions/4967492/about-scalas-assignments-and-setter-methods

It looks both wacky and powerful, and I'm still thinking through the implications, but it may well be useful in building a DSL for this sort of thing.

On 2 Mar 2011 13:21, "Daniel Dekany" <ddekany <at> freemail.hu> wrote:
Kris Nuttycombe | 3 Mar 02:04 2011
Picon

Re: var/val members aren't powerful enough to implement the "property" concept

The only thing out of this discussion that genuinely seems like a good
idea to me is allowing the  <at> BeanProperty annotation to target methods.
That's the major pain point for interop between Scala properties and
Java libraries.

Kris


Gmane