I had heard there were problems and it is certainly true that the
tradtional linked list is slow. I don't think it is just a problem on
the JVM though. Haskell has similar problems and the mechanism I use
in PEC is a possible approach for them. The PEC mechinism is the same
as String in Java with the companion StringBuilder class.
On Dec 9, 3:23 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:
> Scala's lists are immutable, yes. But they aren't thread-safe.
>
> That's because internally scala lists *ARE* mutable. In an attempt to
> work around JVM limitations and make scala fast, scala lists are
> actually mutable for a while as long as nobody reads them, in order to
> make repeated adds fast. So, this:
>
> [a :: b :: c :: d :: e :: Nil]
>
> in scala does NOT in fact create 4 lists. It creates just one and
> makes a bunch of add calls.
>
> Unfortunately, even Odersky's out of this world genius is fallible.
> Specifically, there are conditions where a shared immutable list in
> scala cause multi threading bugs. you know the type - impossible to
> debug, tend to never show up when a debugger is running, race
> conditions, bugs that are only reproducible on 2-core or even 4-core
> systems, and in general pains that can take you years to solve.
>
> Long story short: Scala is not a panacea. In fact, in this particular
> aspect, Scala sucks.
>
> Silver lining in this thundercloud? The regulars on FreeNode #scala
> have submitted patches, which are only a little slower than the
> current implementation and definitely safe.
>
> On Dec 5, 11:09 am, "Viktor Klang" <[EMAIL PROTECTED]> wrote:
>
> > Yes, I agree, arrays is a lame "corner"-case.
>
> > However, my opinion is that the concept of array as in "contigous memory
> > area that is efficient for a processor to process" is an
> > implementation/optimization feature, and not a language feature.
> > While I fully agree that many programmers couldn't live without the precious
> > array, I truely hope that a VM could use them "under the hood" to provide
> > better performance for certain List use-cases.
>
> > In Java, you could probably manage very well with only Buffer and ArrayList.
>
> > Scala Lists are immutable, and can therefor be shared freely.
>
> > What's your take on this?
>
> > Cheers,
> > Viktor
>
> > On Thu, Dec 4, 2008 at 11:33 PM, hlovatt <[EMAIL PROTECTED]> wrote:
>
> > > The Scala case classes only do the simple cases, consider:
>
> > > object Main {
> > > case class Foo( values : Array[Int] ) {
> > > var anotherValue : Int = 1
> > > }
>
> > > def main( args : Array[String] ) = {
> > > val a = Array( 1, 2, 3 )
> > > val f1 = Foo( a )
> > > println( f1.values.toString )
> > > a(0) = 2
> > > println( f1.values.toString )
> > > val f2 = Foo( a )
> > > f2.anotherValue = 2
> > > println( f1 == f2 )
> > > }
> > > }
>
> > > It prints:
>
> > > Array(1, 2, 3)
> > > Array(2, 2, 3)
> > > true
>
> > > So no it doesn't deep copy arguments and it also only uses the fields
> > > of the constructor for equals, hash, etc. and not any other fields.
> > > The facilities in PEC solve both these problems (http://
> > > pec.dev.java.net/compile/javadoc/pec/compile/immutable/
> > > AbstractImmutable.html<http://pec.dev.java.net/compile/javadoc/pec/compile/immutable/Abstrac...>
> > > ).
>
> > > On Dec 5, 9:10 am, "Michael Lee" <[EMAIL PROTECTED]> wrote:
> > > > Does Scalar support the defensive copy of mutable attributes? For
> > > examples,
> > > > if the constructor takes in in an array, does it automatically 'clone'
> > > the
> > > > array for internal attribute? How about 'get' method?
> > > > Thanks in advance.
>
> > > > On Thu, Dec 4, 2008 at 4:05 PM, Viktor Klang <[EMAIL PROTECTED]>
> > > wrote:
> > > > > What I do in Scala:
>
> > > > > case class Person(val firstName : String, val lastName : String)
>
> > > > > then I get correct equals, hashCode, a toString and pattern-matching
> > > and a
> > > > > concise creation syntax:
>
> > > > > val person = Person("Keith","Haber")
>
> > > > > So instead of 30+ lines of Java, I get 1 line of Scala, with more
> > > > > functionality ;)
>
> > > > > </endShamelessPlug>
>
> > > > > :)
>
> > > > > On Thu, Dec 4, 2008 at 5:45 PM, Keith Haber <[EMAIL PROTECTED]> wrote:
>
> > > > >> When I want to make an immutable type with a lot of attributes. I
> > > > >> generally like to use a static inner class as a builder object.
> > > > >> Here's an example with just two attributes.
>
> > > > >> public final class Person{
>
> > > > >> private final String firstName;
> > > > >> private final String lastName;
>
> > > > >> public Person(String firstName, String lastName){
> > > > >> super();
> > > > >> this.firstName = firstName;
> > > > >> this.lastName = lastName;
> > > > >> }
>
> > > > >> public String getFirstName(){return firstName;}
> > > > >> public String getLastName(){return lastName;}
>
> > > > >> public static class Builder {
> > > > >> private String firstName;
> > > > >> private String lastName;
>
> > > > >> public Builder setFirstName(String firstName){
> > > > >> this.firstName = firstName;
> > > > >> return this;
> > > > >> }
>
> > > > >> public Builder setLastName(String lastName){
> > > > >> this.lastName = lastName;
> > > > >> return this;
> > > > >> }
>
> > > > >> public Person newPerson(){
> > > > >> return new Person(firstName, lastName);
> > > > >> }
> > > > >> }
>
> > > > >> }
>
> > > > >> Then in my client code, I would do:
>
> > > > >> Person keith = new Person.Builder().setFirstName
> > > > >> ("Keith").setLastName("Haber").newPerson();
>
> > > > >> Or if I need to instantiate a lot of similar objects, I can hang on
> > > > >> to
> > > > >> my Builder object. (Could be handy for constructing relatives, I
> > > > >> suppose.)
>
> > > > >> A nice thing about this approach is that I get the benefit of
> > > > >> readable
> > > > >> setters instead of working with long lists of meticulously ordered
> > > > >> constructor arguments (not so big a deal with two attributes, but
> > > > >> very
> > > > >> helpful when working with six or more attributes), but my immutable
> > > > >> objects don't have setters at all.
>
> > > > >> And by making the builder class a static inner class, it's obvious
> > > > >> which builder classes go with which immutable types -- it's always
> > > > >> named <immutable type name>.Builder.
>
> > > > >> In episode 219 they talked about objects having a "construct phase"
> > > > >> with setters and a "use phase" when the object construction is
> > > > >> "finished." To my mind this approach is reasonably close to that
> > > > >> idea.
>
> > > > >> Keith
>
> > > > >> On Dec 3, 10:58 pm, hlovatt <[EMAIL PROTECTED]> wrote:
> > > > >> > In 219 there was a long discussion about setting up an object and
> > > then
> > > > >> > making it immutable. There are a couple of ways of doing this in
> > > Java
> > > > >> > already:
>
> > > > >> > public class FooArgs {
> > > > >> > public int x = 1; // 1 is default
> > > > >> > public int y = 2;
> > > > >> > public int z = 3;
> > > > >> > ...
>
> > > > >> > }
>
> > > > >> > public class Foo {
> > > > >> > public Foo( FooArgs args ) { ... }
> > > > >> > ...
>
> > > > >> > }
>
> > > > >> > Foo foo = new Foo( new FooArgs() {{ x = 2 }} );
>
> > > > >> > Another option is an immutable and mutable versions that inherit
> > > from
> > > > >> > a common base and implement a standard conversion interface. First
> > > the
> > > > >> > standard interface:
>
> > > > >> > public interface ImmutableValueConversions {
> > > > >> > Immutable toImmutable() throws IllegalStateException;
> > > > >> > Value toValue();
>
> > > > >> > }
>
> > > > >> > Below is an integer example that uses an abstract class as the base
> > > of
> > > > >> > the hierarchy. You can also use interfaces. The abstract class is:
>
> > > > >> > 8:public abstract class AbstractInteger extends AbstractValue
> > > > >> > 9: implements ImmutableValueConversions, InstanceFactory {
> > > > >> > 10: public abstract int getValue();
> > > > >> > 11:
> > > > >> > 12: public abstract AbstractInteger instanceOfSelf( int value
> > > );
> > > > >> > 13:
> > > > >> > 14: public AbstractInteger add( final int rhs ) {
> > > > >> > 15: return instanceOfSelf( getValue() + rhs );
> > > > >> > 16: }
> > > > >> > 17:}
>
> > > > >> > Then the immutable version:
>
> > > > >> > 9:public final class ImmutableInteger2 extends AbstractInteger
> > > > >> > 10: implements Immutable {
> > > > >> > 11: private final int value;
> > > > >> > 12:
> > > > >> > 13: public ImmutableInteger2( final int value ) {
> > > > >> > 14: this.value = value;
> > > > >> > 15: }
> > > > >> > 16:
> > > > >> > 17: public int getValue() {
> > > > >> > 18: return value;
> > > > >> > 19: }
> > > > >> > 20:
> > > > >> > 21: public Immutable toImmutable() {
> > > > >> > 22: return this;
> > > > >> > 23: }
> > > > >> > 24:
> > > > >> > 25: public Value toValue() {
> > > > >> > 26: return new ValueInteger( value );
> > > > >> > 27: }
> > > > >> > 28:
> > > > >> > 29: public AbstractInteger instanceOfSelf( final int value )
> > > > >> > {
> > > > >> > 30: return new ImmutableInteger2( value );
> > > > >> > 31: }
> > > > >> > 38:}
>
> > > > >> > And the value version:
>
> > > > >> > 9:public final class ValueInteger extends AbstractInteger {
> > > > >> > 10: // Not final, this is the value version
> > > > >> > 11: private int value;
> > > > >> > 12:
> > > > >> > 13: public ValueInteger( final int value ) {
> > > > >> > 14: this.value = value;
> > > > >> > 15: }
> > > > >> > 16:
> > > > >> > 17: public int getValue() {
> > > > >> > 18: return value;
> > > > >> > 19: }
> > > > >> > 20:
> > > > >> > 21: // Setter, this is the value version!
> > > > >> > 22: public void setValue( final int value ) {
> > > > >> > 23: this.value = value;
> > > > >> > 24: }
> > > > >> > 25:
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
