Why Array requires Manifest while ArrayBuffer does not?

Basically, ArrayBuffer is a parameterized class, and, therefore, erased. Array is more like a primitive, and it is NOT type erased. So the actual type is required at run-time to initialize it.

On Wed, Apr 21, 2010 at 10:51 PM, calathus <calathus@gmail.com> wrote:

Hi,
I was annoyed to provide Minifest for a method using Array. And I
found this is not required if we use ArrayBuffer.
See following codes. f0 cause compilation error, and if we provide
manifest (f1), it was compiled.
but if we use ArrayBuffer, it does not require Manifest specification.
What is the reason behind this difference of behavior?

Also if it can resolve the problem by providing Manifest(without
understanding the mechanism;-)), why it does not automatically add
manifest??

 def f0A]() = {
   val arr = new Array[A](3)// error: cannot find class manifest for
element type A
 }

 def f1[A: Manifest]() = {
   val arr = new Array[A](3)// OK, but need to specify Manifest
 }

 def f2[A]() = {
   val arr = new ArrayBuffer[A](3)// OK, no need to specify Manifest
 }

nc

http://scalathus.blogspot.com

--
Daniel C. Sobral

I travel to the future all the time.

Thank you for clear answer.

Does it mean the main use scenario of Scala's Array class is to invoke
Java method in which array parameter is used?
It is simpler to use parametrized class which does not require Manifest.
I compared the performance of ArrayBuffer with Array, and I found
ArrayBuffer perform better than Array(of course, this would depend on
test case).
But as long as its internal data structure is represented by Java
array, it looks better to use always ArrayBuffer instead of Array.

nc

On Wed, Apr 21, 2010 at 7:25 PM, Daniel Sobral wrote:
> Basically, ArrayBuffer is a parameterized class, and, therefore, erased.
> Array is more like a primitive, and it is NOT type erased. So the actual
> type is required at run-time to initialize it.
>
> On Wed, Apr 21, 2010 at 10:51 PM, calathus wrote:
>>
>> Hi,
>> I was annoyed to provide Minifest for a method using Array. And I
>> found this is not required if we use ArrayBuffer.
>> See following codes. f0 cause compilation error, and if we provide
>> manifest (f1), it was compiled.
>> but if we use ArrayBuffer, it does not require Manifest specification.
>> What is the reason behind this difference of behavior?
>>
>> Also if it can resolve the problem by providing Manifest(without
>> understanding the mechanism;-)), why it does not automatically add
>> manifest??
>>
>>  def f0A]() = {
>>    val arr = new Array[A](3)// error: cannot find class manifest for
>> element type A
>>  }
>>
>>  def f1[A: Manifest]() = {
>>    val arr = new Array[A](3)// OK, but need to specify Manifest
>>  }
>>
>>  def f2[A]() = {
>>    val arr = new ArrayBuffer[A](3)// OK, no need to specify Manifest
>>  }
>>
>> nc
>>
>> http://scalathus.blogspot.com
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

http://scalathus.blogspot.com

> But as long as its internal data structure is represented by Java
> array, it looks better to use always ArrayBuffer instead of Array.

If we want to optimize space usage etc, it may be better to use Array,
but are there any such runtime advantage? What is the conceivable pros
and cons of Array and ArrayBuffer?

nc

>
> nc
>
>
> On Wed, Apr 21, 2010 at 7:25 PM, Daniel Sobral wrote:
>> Basically, ArrayBuffer is a parameterized class, and, therefore, erased.
>> Array is more like a primitive, and it is NOT type erased. So the actual
>> type is required at run-time to initialize it.
>>
>> On Wed, Apr 21, 2010 at 10:51 PM, calathus wrote:
>>>
>>> Hi,
>>> I was annoyed to provide Minifest for a method using Array. And I
>>> found this is not required if we use ArrayBuffer.
>>> See following codes. f0 cause compilation error, and if we provide
>>> manifest (f1), it was compiled.
>>> but if we use ArrayBuffer, it does not require Manifest specification.
>>> What is the reason behind this difference of behavior?
>>>
>>> Also if it can resolve the problem by providing Manifest(without
>>> understanding the mechanism;-)), why it does not automatically add
>>> manifest??
>>>
>>>  def f0A]() = {
>>>    val arr = new Array[A](3)// error: cannot find class manifest for
>>> element type A
>>>  }
>>>
>>>  def f1[A: Manifest]() = {
>>>    val arr = new Array[A](3)// OK, but need to specify Manifest
>>>  }
>>>
>>>  def f2[A]() = {
>>>    val arr = new ArrayBuffer[A](3)// OK, no need to specify Manifest
>>>  }
>>>
>>> nc
>>>
>>> http://scalathus.blogspot.com
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>>
>
>
> http://scalathus.blogspot.com
>

Array can store primitive types. ArrayBuffer boxes them first (so far, anyway; could conceivably change in the future with specialization).  If you try a large Array[Int], it will work faster than ArrayBuffer unless you're doing the wrong test.  (E.g. if you call something that has to box every int, then you're better off with ArrayBuffer.)

That said, usually ArrayBuffer is plenty fast enough, and it is a proper collection, so you get all the nifty map/filter stuff without having to box it.  (Array needs to be implicitly boxed for the standard collections methods to work.)

  --Rex

On Wed, Apr 21, 2010 at 11:20 PM, calathus <calathus@gmail.com> wrote:

> But as long as its internal data structure is represented by Java
> array, it looks better to use always ArrayBuffer instead of Array.

If we want to optimize space usage etc, it may be better to use Array,
but are there any such runtime advantage? What is the conceivable pros
and cons of Array and ArrayBuffer?

nc

>
> nc
>
>
> On Wed, Apr 21, 2010 at 7:25 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
>> Basically, ArrayBuffer is a parameterized class, and, therefore, erased.
>> Array is more like a primitive, and it is NOT type erased. So the actual
>> type is required at run-time to initialize it.
>>
>> On Wed, Apr 21, 2010 at 10:51 PM, calathus <calathus@gmail.com> wrote:
>>>
>>> Hi,
>>> I was annoyed to provide Minifest for a method using Array. And I
>>> found this is not required if we use ArrayBuffer.
>>> See following codes. f0 cause compilation error, and if we provide
>>> manifest (f1), it was compiled.
>>> but if we use ArrayBuffer, it does not require Manifest specification.
>>> What is the reason behind this difference of behavior?
>>>
>>> Also if it can resolve the problem by providing Manifest(without
>>> understanding the mechanism;-)), why it does not automatically add
>>> manifest??
>>>
>>>  def f0A]() = {
>>>    val arr = new Array[A](3)// error: cannot find class manifest for
>>> element type A
>>>  }
>>>
>>>  def f1[A: Manifest]() = {
>>>    val arr = new Array[A](3)// OK, but need to specify Manifest
>>>  }
>>>
>>>  def f2[A]() = {
>>>    val arr = new ArrayBuffer[A](3)// OK, no need to specify Manifest
>>>  }
>>>
>>> nc
>>>
>>> http://scalathus.blogspot.com
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>>
>
>
> http://scalathus.blogspot.com
>



--
cheer,
nc

http://scalathus.blogspot.com

What do you mean by box?
Would it mean the conversion between primitive(int) and Object(Integer) type?
But if it is the case, how can we avoid these conversion. at Scala
level, they are only represented by Int..

On Wed, Apr 21, 2010 at 9:18 PM, Rex Kerr wrote:
> Array can store primitive types. ArrayBuffer boxes them first (so far,
> anyway; could conceivably change in the future with specialization).  If you
> try a large Array[Int], it will work faster than ArrayBuffer unless you're
> doing the wrong test.  (E.g. if you call something that has to box every
> int, then you're better off with ArrayBuffer.)
>
> That said, usually ArrayBuffer is plenty fast enough, and it is a proper
> collection, so you get all the nifty map/filter stuff without having to box
> it.  (Array needs to be implicitly boxed for the standard collections
> methods to work.)
>
>   --Rex
>
> On Wed, Apr 21, 2010 at 11:20 PM, calathus wrote:
>>
>> > But as long as its internal data structure is represented by Java
>> > array, it looks better to use always ArrayBuffer instead of Array.
>>
>> If we want to optimize space usage etc, it may be better to use Array,
>> but are there any such runtime advantage? What is the conceivable pros
>> and cons of Array and ArrayBuffer?
>>
>> nc
>>
>> >
>> > nc
>> >
>> >
>> > On Wed, Apr 21, 2010 at 7:25 PM, Daniel Sobral
>> > wrote:
>> >> Basically, ArrayBuffer is a parameterized class, and, therefore,
>> >> erased.
>> >> Array is more like a primitive, and it is NOT type erased. So the
>> >> actual
>> >> type is required at run-time to initialize it.
>> >>
>> >> On Wed, Apr 21, 2010 at 10:51 PM, calathus wrote:
>> >>>
>> >>> Hi,
>> >>> I was annoyed to provide Minifest for a method using Array. And I
>> >>> found this is not required if we use ArrayBuffer.
>> >>> See following codes. f0 cause compilation error, and if we provide
>> >>> manifest (f1), it was compiled.
>> >>> but if we use ArrayBuffer, it does not require Manifest specification.
>> >>> What is the reason behind this difference of behavior?
>> >>>
>> >>> Also if it can resolve the problem by providing Manifest(without
>> >>> understanding the mechanism;-)), why it does not automatically add
>> >>> manifest??
>> >>>
>> >>>  def f0A]() = {
>> >>>    val arr = new Array[A](3)// error: cannot find class manifest for
>> >>> element type A
>> >>>  }
>> >>>
>> >>>  def f1[A: Manifest]() = {
>> >>>    val arr = new Array[A](3)// OK, but need to specify Manifest
>> >>>  }
>> >>>
>> >>>  def f2[A]() = {
>> >>>    val arr = new ArrayBuffer[A](3)// OK, no need to specify Manifest
>> >>>  }
>> >>>
>> >>> nc
>> >>>
>> >>> http://scalathus.blogspot.com
>> >>
>> >>
>> >>
>> >> --
>> >> Daniel C. Sobral
>> >>
>> >> I travel to the future all the time.
>> >>
>> >
>> >
>> > http://scalathus.blogspot.com
>> >
>>
>>
>>
>> --
>> cheer,
>> nc
>>
>> http://scalathus.blogspot.com
>
>

i thinke he means simpleobject.extraMethod() -> compiler transforms it to new RichX(simpleobject).extraMethod()
-------- Original-Nachricht --------
> Datum: Wed, 21 Apr 2010 22:59:17 -0700
> Von: calathus
> An: Rex Kerr
> CC: Scala Users
> Betreff: Re: [scala-user]Why Array requires Manifest while ArrayBuffer does not?

> What do you mean by box?
> Would it mean the conversion between primitive(int) and Object(Integer)
> type?
> But if it is the case, how can we avoid these conversion. at Scala
> level, they are only represented by Int..
>
>
> On Wed, Apr 21, 2010 at 9:18 PM, Rex Kerr wrote:
> > Array can store primitive types. ArrayBuffer boxes them first (so far,
> > anyway; could conceivably change in the future with specialization). 
> If you
> > try a large Array[Int], it will work faster than ArrayBuffer unless
> you're
> > doing the wrong test.  (E.g. if you call something that has to box
> every
> > int, then you're better off with ArrayBuffer.)
> >
> > That said, usually ArrayBuffer is plenty fast enough, and it is a proper
> > collection, so you get all the nifty map/filter stuff without having to
> box
> > it.  (Array needs to be implicitly boxed for the standard collections
> > methods to work.)
> >
> >   --Rex
> >
> > On Wed, Apr 21, 2010 at 11:20 PM, calathus wrote:
> >>
> >> > But as long as its internal data structure is represented by Java
> >> > array, it looks better to use always ArrayBuffer instead of Array.
> >>
> >> If we want to optimize space usage etc, it may be better to use Array,
> >> but are there any such runtime advantage? What is the conceivable pros
> >> and cons of Array and ArrayBuffer?
> >>
> >> nc
> >>
> >> >
> >> > nc
> >> >
> >> >
> >> > On Wed, Apr 21, 2010 at 7:25 PM, Daniel Sobral
> >> > wrote:
> >> >> Basically, ArrayBuffer is a parameterized class, and, therefore,
> >> >> erased.
> >> >> Array is more like a primitive, and it is NOT type erased. So the
> >> >> actual
> >> >> type is required at run-time to initialize it.
> >> >>
> >> >> On Wed, Apr 21, 2010 at 10:51 PM, calathus
> wrote:
> >> >>>
> >> >>> Hi,
> >> >>> I was annoyed to provide Minifest for a method using Array. And I
> >> >>> found this is not required if we use ArrayBuffer.
> >> >>> See following codes. f0 cause compilation error, and if we provide
> >> >>> manifest (f1), it was compiled.
> >> >>> but if we use ArrayBuffer, it does not require Manifest
> specification.
> >> >>> What is the reason behind this difference of behavior?
> >> >>>
> >> >>> Also if it can resolve the problem by providing Manifest(without
> >> >>> understanding the mechanism;-)), why it does not automatically add
> >> >>> manifest??
> >> >>>
> >> >>>  def f0A]() = {
> >> >>>    val arr = new Array[A](3)// error: cannot find class manifest
> for
> >> >>> element type A
> >> >>>  }
> >> >>>
> >> >>>  def f1[A: Manifest]() = {
> >> >>>    val arr = new Array[A](3)// OK, but need to specify Manifest
> >> >>>  }
> >> >>>
> >> >>>  def f2[A]() = {
> >> >>>    val arr = new ArrayBuffer[A](3)// OK, no need to specify
> Manifest
> >> >>>  }
> >> >>>
> >> >>> nc
> >> >>>
> >> >>> http://scalathus.blogspot.com
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Daniel C. Sobral
> >> >>
> >> >> I travel to the future all the time.
> >> >>
> >> >
> >> >
> >> > http://scalathus.blogspot.com
> >> >
> >>
> >>
> >>
> >> --
> >> cheer,
> >> nc
> >>
> >> http://scalathus.blogspot.com
> >
> >
>
>
>

On Thu, Apr 22, 2010 at 12:20 AM, Dennis Haupt wrote:
> i thinke he means simpleobject.extraMethod() -> compiler transforms it to new RichX(simpleobject).extraMethod()

So the following code:

val arr = new Array[Int](1000)
for (i <- 0 until 1000) {
arr(i) = i
val a = arr(i)
}

will be translated into:

val arr = new Array[Int](1000)
for (i <- 0 until 1000) {
new RichX(arr).set(i, i)
val a = new RichX(arr).get(i)
}

? It generate a lot of garbage!
If this is the case, it looks better to avoid Array for most of the use cases.

nc

> -------- Original-Nachricht --------
>> Datum: Wed, 21 Apr 2010 22:59:17 -0700
>> Von: calathus
>> An: Rex Kerr
>> CC: Scala Users
>> Betreff: Re: [scala-user]Why Array requires Manifest while ArrayBuffer does   not?
>
>> What do you mean by box?
>> Would it mean the conversion between primitive(int) and Object(Integer)
>> type?
>> But if it is the case, how can we avoid these conversion. at Scala
>> level, they are only represented by Int..
>>
>>
>> On Wed, Apr 21, 2010 at 9:18 PM, Rex Kerr wrote:
>> > Array can store primitive types. ArrayBuffer boxes them first (so far,
>> > anyway; could conceivably change in the future with specialization).
>> If you
>> > try a large Array[Int], it will work faster than ArrayBuffer unless
>> you're
>> > doing the wrong test.  (E.g. if you call something that has to box
>> every
>> > int, then you're better off with ArrayBuffer.)
>> >
>> > That said, usually ArrayBuffer is plenty fast enough, and it is a proper
>> > collection, so you get all the nifty map/filter stuff without having to
>> box
>> > it.  (Array needs to be implicitly boxed for the standard collections
>> > methods to work.)
>> >
>> >   --Rex
>> >
>> > On Wed, Apr 21, 2010 at 11:20 PM, calathus wrote:
>> >>
>> >> > But as long as its internal data structure is represented by Java
>> >> > array, it looks better to use always ArrayBuffer instead of Array.
>> >>
>> >> If we want to optimize space usage etc, it may be better to use Array,
>> >> but are there any such runtime advantage? What is the conceivable pros
>> >> and cons of Array and ArrayBuffer?
>> >>
>> >> nc
>> >>
>> >> >
>> >> > nc
>> >> >
>> >> >
>> >> > On Wed, Apr 21, 2010 at 7:25 PM, Daniel Sobral
>> >> > wrote:
>> >> >> Basically, ArrayBuffer is a parameterized class, and, therefore,
>> >> >> erased.
>> >> >> Array is more like a primitive, and it is NOT type erased. So the
>> >> >> actual
>> >> >> type is required at run-time to initialize it.
>> >> >>
>> >> >> On Wed, Apr 21, 2010 at 10:51 PM, calathus
>> wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>> I was annoyed to provide Minifest for a method using Array. And I
>> >> >>> found this is not required if we use ArrayBuffer.
>> >> >>> See following codes. f0 cause compilation error, and if we provide
>> >> >>> manifest (f1), it was compiled.
>> >> >>> but if we use ArrayBuffer, it does not require Manifest
>> specification.
>> >> >>> What is the reason behind this difference of behavior?
>> >> >>>
>> >> >>> Also if it can resolve the problem by providing Manifest(without
>> >> >>> understanding the mechanism;-)), why it does not automatically add
>> >> >>> manifest??
>> >> >>>
>> >> >>>  def f0A]() = {
>> >> >>>    val arr = new Array[A](3)// error: cannot find class manifest
>> for
>> >> >>> element type A
>> >> >>>  }
>> >> >>>
>> >> >>>  def f1[A: Manifest]() = {
>> >> >>>    val arr = new Array[A](3)// OK, but need to specify Manifest
>> >> >>>  }
>> >> >>>
>> >> >>>  def f2[A]() = {
>> >> >>>    val arr = new ArrayBuffer[A](3)// OK, no need to specify
>> Manifest
>> >> >>>  }
>> >> >>>
>> >> >>> nc
>> >> >>>
>> >> >>> http://scalathus.blogspot.com
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Daniel C. Sobral
>> >> >>
>> >> >> I travel to the future all the time.
>> >> >>
>> >> >
>> >> >
>> >> > http://scalathus.blogspot.com
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> cheer,
>> >> nc
>> >>
>> >> http://scalathus.blogspot.com
>> >
>> >
>>
>>
>>
>> --
>> cheer,
>> nc
>>
>> http://scalathus.blogspot.com
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>

Not RichX. I think java.lang.Integer is more likely.
But, actually, Array[Int] stores the stuff as "int". It's ArrayBuffer[Int] which will store them as java.lang.Integer.

On Thu, Apr 22, 2010 at 5:09 AM, calathus <calathus@gmail.com> wrote:

On Thu, Apr 22, 2010 at 12:20 AM, Dennis Haupt <h-star@gmx.de> wrote:
> i thinke he means simpleobject.extraMethod() -> compiler transforms it to new RichX(simpleobject).extraMethod()

So the following code:

val arr = new Array[Int](1000)
for (i <- 0 until 1000) {
  arr(i) = i
  val a = arr(i)
}

will be translated into:

val arr = new Array[Int](1000)
for (i <- 0 until 1000) {
  new RichX(arr).set(i, i)
  val a = new RichX(arr).get(i)
}

? It generate a lot of garbage!
If this is the case, it looks better to avoid Array for most of the use cases.

nc

> -------- Original-Nachricht --------
>> Datum: Wed, 21 Apr 2010 22:59:17 -0700
>> Von: calathus <calathus@gmail.com>
>> An: Rex Kerr <ichoran@gmail.com>
>> CC: Scala Users <scala-user@listes.epfl.ch>
>> Betreff: Re: [scala-user]Why Array requires Manifest while ArrayBuffer does   not?
>
>> What do you mean by box?
>> Would it mean the conversion between primitive(int) and Object(Integer)
>> type?
>> But if it is the case, how can we avoid these conversion. at Scala
>> level, they are only represented by Int..
>>
>>
>> On Wed, Apr 21, 2010 at 9:18 PM, Rex Kerr <ichoran@gmail.com> wrote:
>> > Array can store primitive types. ArrayBuffer boxes them first (so far,
>> > anyway; could conceivably change in the future with specialization).
>> If you
>> > try a large Array[Int], it will work faster than ArrayBuffer unless
>> you're
>> > doing the wrong test.  (E.g. if you call something that has to box
>> every
>> > int, then you're better off with ArrayBuffer.)
>> >
>> > That said, usually ArrayBuffer is plenty fast enough, and it is a proper
>> > collection, so you get all the nifty map/filter stuff without having to
>> box
>> > it.  (Array needs to be implicitly boxed for the standard collections
>> > methods to work.)
>> >
>> >   --Rex
>> >
>> > On Wed, Apr 21, 2010 at 11:20 PM, calathus <calathus@gmail.com> wrote:
>> >>
>> >> > But as long as its internal data structure is represented by Java
>> >> > array, it looks better to use always ArrayBuffer instead of Array.
>> >>
>> >> If we want to optimize space usage etc, it may be better to use Array,
>> >> but are there any such runtime advantage? What is the conceivable pros
>> >> and cons of Array and ArrayBuffer?
>> >>
>> >> nc
>> >>
>> >> >
>> >> > nc
>> >> >
>> >> >
>> >> > On Wed, Apr 21, 2010 at 7:25 PM, Daniel Sobral <dcsobral@gmail.com>
>> >> > wrote:
>> >> >> Basically, ArrayBuffer is a parameterized class, and, therefore,
>> >> >> erased.
>> >> >> Array is more like a primitive, and it is NOT type erased. So the
>> >> >> actual
>> >> >> type is required at run-time to initialize it.
>> >> >>
>> >> >> On Wed, Apr 21, 2010 at 10:51 PM, calathus <calathus@gmail.com>
>> wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>> I was annoyed to provide Minifest for a method using Array. And I
>> >> >>> found this is not required if we use ArrayBuffer.
>> >> >>> See following codes. f0 cause compilation error, and if we provide
>> >> >>> manifest (f1), it was compiled.
>> >> >>> but if we use ArrayBuffer, it does not require Manifest
>> specification.
>> >> >>> What is the reason behind this difference of behavior?
>> >> >>>
>> >> >>> Also if it can resolve the problem by providing Manifest(without
>> >> >>> understanding the mechanism;-)), why it does not automatically add
>> >> >>> manifest??
>> >> >>>
>> >> >>>  def f0A]() = {
>> >> >>>    val arr = new Array[A](3)// error: cannot find class manifest
>> for
>> >> >>> element type A
>> >> >>>  }
>> >> >>>
>> >> >>>  def f1[A: Manifest]() = {
>> >> >>>    val arr = new Array[A](3)// OK, but need to specify Manifest
>> >> >>>  }
>> >> >>>
>> >> >>>  def f2[A]() = {
>> >> >>>    val arr = new ArrayBuffer[A](3)// OK, no need to specify
>> Manifest
>> >> >>>  }
>> >> >>>
>> >> >>> nc
>> >> >>>
>> >> >>> http://scalathus.blogspot.com
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Daniel C. Sobral
>> >> >>
>> >> >> I travel to the future all the time.
>> >> >>
>> >> >
>> >> >
>> >> > http://scalathus.blogspot.com
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> cheer,
>> >> nc
>> >>
>> >> http://scalathus.blogspot.com
>> >
>> >
>>
>>
>>
>> --
>> cheer,
>> nc
>>
>> http://scalathus.blogspot.com
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>



--
cheer,
nc

http://scalathus.blogspot.com

--
Daniel C. Sobral

I travel to the future all the time.

are you sure? i'd have guess id would be translated to

val arr = new int[1000]
for (i <- 0 until 1000) {
arr[i] = i
val a = arr[i]
}

because the richX-stuff makes absolutely no sense for get and set, the primitive vm array already supports this

-------- Original-Nachricht --------
> Datum: Thu, 22 Apr 2010 10:08:41 -0300
> Von: Daniel Sobral
> An: calathus
> CC: Dennis Haupt , ichoran@gmail.com, scala-user@listes.epfl.ch
> Betreff: Re: [scala-user]Why Array requires Manifest while ArrayBuffer does not?

> Not RichX. I think java.lang.Integer is more likely.
>
> But, actually, Array[Int] stores the stuff as "int". It's ArrayBuffer[Int]
> which will store them as java.lang.Integer.
>
> On Thu, Apr 22, 2010 at 5:09 AM, calathus wrote:
>
> > On Thu, Apr 22, 2010 at 12:20 AM, Dennis Haupt wrote:
> > > i thinke he means simpleobject.extraMethod() -> compiler transforms it
> to
> > new RichX(simpleobject).extraMethod()
> >
> > So the following code:
> >
> > val arr = new Array[Int](1000)
> > for (i <- 0 until 1000) {
> > arr(i) = i
> > val a = arr(i)
> > }
> >
> > will be translated into:
> >
> > val arr = new Array[Int](1000)
> > for (i <- 0 until 1000) {
> > new RichX(arr).set(i, i)
> > val a = new RichX(arr).get(i)
> > }
> >
> > ? It generate a lot of garbage!
> > If this is the case, it looks better to avoid Array for most of the use
> > cases.
> >
> > nc
> >
> > > -------- Original-Nachricht --------
> > >> Datum: Wed, 21 Apr 2010 22:59:17 -0700
> > >> Von: calathus
> > >> An: Rex Kerr
> > >> CC: Scala Users
> > >> Betreff: Re: [scala-user]Why Array requires Manifest while
> ArrayBuffer
> > does not?
> > >
> > >> What do you mean by box?
> > >> Would it mean the conversion between primitive(int) and
> Object(Integer)
> > >> type?
> > >> But if it is the case, how can we avoid these conversion. at Scala
> > >> level, they are only represented by Int..
> > >>
> > >>
> > >> On Wed, Apr 21, 2010 at 9:18 PM, Rex Kerr wrote:
> > >> > Array can store primitive types. ArrayBuffer boxes them first (so
> far,
> > >> > anyway; could conceivably change in the future with
> specialization).
> > >> If you
> > >> > try a large Array[Int], it will work faster than ArrayBuffer unless
> > >> you're
> > >> > doing the wrong test. (E.g. if you call something that has to box
> > >> every
> > >> > int, then you're better off with ArrayBuffer.)
> > >> >
> > >> > That said, usually ArrayBuffer is plenty fast enough, and it is a
> > proper
> > >> > collection, so you get all the nifty map/filter stuff without
> having
> > to
> > >> box
> > >> > it. (Array needs to be implicitly boxed for the standard
> collections
> > >> > methods to work.)
> > >> >
> > >> > --Rex
> > >> >
> > >> > On Wed, Apr 21, 2010 at 11:20 PM, calathus
> > wrote:
> > >> >>
> > >> >> > But as long as its internal data structure is represented by
> Java
> > >> >> > array, it looks better to use always ArrayBuffer instead of
> Array.
> > >> >>
> > >> >> If we want to optimize space usage etc, it may be better to use
> > Array,
> > >> >> but are there any such runtime advantage? What is the conceivable
> > pros
> > >> >> and cons of Array and ArrayBuffer?
> > >> >>
> > >> >> nc
> > >> >>
> > >> >> >
> > >> >> > nc
> > >> >> >
> > >> >> >
> > >> >> > On Wed, Apr 21, 2010 at 7:25 PM, Daniel Sobral
> > >
> > >> >> > wrote:
> > >> >> >> Basically, ArrayBuffer is a parameterized class, and,
> therefore,
> > >> >> >> erased.
> > >> >> >> Array is more like a primitive, and it is NOT type erased. So
> the
> > >> >> >> actual
> > >> >> >> type is required at run-time to initialize it.
> > >> >> >>
> > >> >> >> On Wed, Apr 21, 2010 at 10:51 PM, calathus
> > >> wrote:
> > >> >> >>>
> > >> >> >>> Hi,
> > >> >> >>> I was annoyed to provide Minifest for a method using Array.
> And I
> > >> >> >>> found this is not required if we use ArrayBuffer.
> > >> >> >>> See following codes. f0 cause compilation error, and if we
> > provide
> > >> >> >>> manifest (f1), it was compiled.
> > >> >> >>> but if we use ArrayBuffer, it does not require Manifest
> > >> specification.
> > >> >> >>> What is the reason behind this difference of behavior?
> > >> >> >>>
> > >> >> >>> Also if it can resolve the problem by providing
> Manifest(without
> > >> >> >>> understanding the mechanism;-)), why it does not automatically
> > add
> > >> >> >>> manifest??
> > >> >> >>>
> > >> >> >>> def f0A]() = {
> > >> >> >>> val arr = new Array[A](3)// error: cannot find class
> manifest
> > >> for
> > >> >> >>> element type A
> > >> >> >>> }
> > >> >> >>>
> > >> >> >>> def f1[A: Manifest]() = {
> > >> >> >>> val arr = new Array[A](3)// OK, but need to specify
> Manifest
> > >> >> >>> }
> > >> >> >>>
> > >> >> >>> def f2[A]() = {
> > >> >> >>> val arr = new ArrayBuffer[A](3)// OK, no need to specify
> > >> Manifest
> > >> >> >>> }
> > >> >> >>>
> > >> >> >>> nc
> > >> >> >>>
> > >> >> >>> http://scalathus.blogspot.com
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >> --
> > >> >> >> Daniel C. Sobral
> > >> >> >>
> > >> >> >> I travel to the future all the time.
> > >> >> >>
> > >> >> >
> > >> >> >
> > >> >> > http://scalathus.blogspot.com
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> cheer,
> > >> >> nc
> > >> >>
> > >> >> http://scalathus.blogspot.com
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> cheer,
> > >> nc
> > >>
> > >> http://scalathus.blogspot.com
> > >
> > > --
> > > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> > >
> >
> >
> >
> > --
> > cheer,
> > nc
> >
> > http://scalathus.blogspot.com
> >
>
>
>

google has proof:
http://www.drmaciver.com/2008/06/scala-arrays/

scala always tries to use primitive arrays if possible.

-------- Original-Nachricht --------
> Datum: Thu, 22 Apr 2010 15:28:07 +0200
> Von: "Dennis Haupt"
> An: Daniel Sobral , calathus@gmail.com
> CC: scala-user@listes.epfl.ch, ichoran@gmail.com
> Betreff: Re: [scala-user]Why Array requires Manifest while ArrayBuffer does not?

> are you sure? i'd have guess id would be translated to
>
> val arr = new int[1000]
> for (i <- 0 until 1000) {
> arr[i] = i
> val a = arr[i]
> }
>
> because the richX-stuff makes absolutely no sense for get and set, the
> primitive vm array already supports this
>
> -------- Original-Nachricht --------
> > Datum: Thu, 22 Apr 2010 10:08:41 -0300
> > Von: Daniel Sobral
> > An: calathus
> > CC: Dennis Haupt , ichoran@gmail.com,
> scala-user@listes.epfl.ch
> > Betreff: Re: [scala-user]Why Array requires Manifest while ArrayBuffer
> does not?
>
> > Not RichX. I think java.lang.Integer is more likely.
> >
> > But, actually, Array[Int] stores the stuff as "int". It's
> ArrayBuffer[Int]
> > which will store them as java.lang.Integer.
> >
> > On Thu, Apr 22, 2010 at 5:09 AM, calathus wrote:
> >
> > > On Thu, Apr 22, 2010 at 12:20 AM, Dennis Haupt wrote:
> > > > i thinke he means simpleobject.extraMethod() -> compiler transforms
> it
> > to
> > > new RichX(simpleobject).extraMethod()
> > >
> > > So the following code:
> > >
> > > val arr = new Array[Int](1000)
> > > for (i <- 0 until 1000) {
> > > arr(i) = i
> > > val a = arr(i)
> > > }
> > >
> > > will be translated into:
> > >
> > > val arr = new Array[Int](1000)
> > > for (i <- 0 until 1000) {
> > > new RichX(arr).set(i, i)
> > > val a = new RichX(arr).get(i)
> > > }
> > >
> > > ? It generate a lot of garbage!
> > > If this is the case, it looks better to avoid Array for most of the
> use
> > > cases.
> > >
> > > nc
> > >
> > > > -------- Original-Nachricht --------
> > > >> Datum: Wed, 21 Apr 2010 22:59:17 -0700
> > > >> Von: calathus
> > > >> An: Rex Kerr
> > > >> CC: Scala Users
> > > >> Betreff: Re: [scala-user]Why Array requires Manifest while
> > ArrayBuffer
> > > does not?
> > > >
> > > >> What do you mean by box?
> > > >> Would it mean the conversion between primitive(int) and
> > Object(Integer)
> > > >> type?
> > > >> But if it is the case, how can we avoid these conversion. at Scala
> > > >> level, they are only represented by Int..
> > > >>
> > > >>
> > > >> On Wed, Apr 21, 2010 at 9:18 PM, Rex Kerr
> wrote:
> > > >> > Array can store primitive types. ArrayBuffer boxes them first (so
> > far,
> > > >> > anyway; could conceivably change in the future with
> > specialization).
> > > >> If you
> > > >> > try a large Array[Int], it will work faster than ArrayBuffer
> unless
> > > >> you're
> > > >> > doing the wrong test. (E.g. if you call something that has to
> box
> > > >> every
> > > >> > int, then you're better off with ArrayBuffer.)
> > > >> >
> > > >> > That said, usually ArrayBuffer is plenty fast enough, and it is a
> > > proper
> > > >> > collection, so you get all the nifty map/filter stuff without
> > having
> > > to
> > > >> box
> > > >> > it. (Array needs to be implicitly boxed for the standard
> > collections
> > > >> > methods to work.)
> > > >> >
> > > >> > --Rex
> > > >> >
> > > >> > On Wed, Apr 21, 2010 at 11:20 PM, calathus
> > > wrote:
> > > >> >>
> > > >> >> > But as long as its internal data structure is represented by
> > Java
> > > >> >> > array, it looks better to use always ArrayBuffer instead of
> > Array.
> > > >> >>
> > > >> >> If we want to optimize space usage etc, it may be better to use
> > > Array,
> > > >> >> but are there any such runtime advantage? What is the
> conceivable
> > > pros
> > > >> >> and cons of Array and ArrayBuffer?
> > > >> >>
> > > >> >> nc
> > > >> >>
> > > >> >> >
> > > >> >> > nc
> > > >> >> >
> > > >> >> >
> > > >> >> > On Wed, Apr 21, 2010 at 7:25 PM, Daniel Sobral
> > > > >
> > > >> >> > wrote:
> > > >> >> >> Basically, ArrayBuffer is a parameterized class, and,
> > therefore,
> > > >> >> >> erased.
> > > >> >> >> Array is more like a primitive, and it is NOT type erased. So
> > the
> > > >> >> >> actual
> > > >> >> >> type is required at run-time to initialize it.
> > > >> >> >>
> > > >> >> >> On Wed, Apr 21, 2010 at 10:51 PM, calathus
>
> > > >> wrote:
> > > >> >> >>>
> > > >> >> >>> Hi,
> > > >> >> >>> I was annoyed to provide Minifest for a method using Array.
> > And I
> > > >> >> >>> found this is not required if we use ArrayBuffer.
> > > >> >> >>> See following codes. f0 cause compilation error, and if we
> > > provide
> > > >> >> >>> manifest (f1), it was compiled.
> > > >> >> >>> but if we use ArrayBuffer, it does not require Manifest
> > > >> specification.
> > > >> >> >>> What is the reason behind this difference of behavior?
> > > >> >> >>>
> > > >> >> >>> Also if it can resolve the problem by providing
> > Manifest(without
> > > >> >> >>> understanding the mechanism;-)), why it does not
> automatically
> > > add
> > > >> >> >>> manifest??
> > > >> >> >>>
> > > >> >> >>> def f0A]() = {
> > > >> >> >>> val arr = new Array[A](3)// error: cannot find class
> > manifest
> > > >> for
> > > >> >> >>> element type A
> > > >> >> >>> }
> > > >> >> >>>
> > > >> >> >>> def f1[A: Manifest]() = {
> > > >> >> >>> val arr = new Array[A](3)// OK, but need to specify
> > Manifest
> > > >> >> >>> }
> > > >> >> >>>
> > > >> >> >>> def f2[A]() = {
> > > >> >> >>> val arr = new ArrayBuffer[A](3)// OK, no need to specify
> > > >> Manifest
> > > >> >> >>> }
> > > >> >> >>>
> > > >> >> >>> nc
> > > >> >> >>>
> > > >> >> >>> http://scalathus.blogspot.com
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>
> > > >> >> >> --
> > > >> >> >> Daniel C. Sobral
> > > >> >> >>
> > > >> >> >> I travel to the future all the time.
> > > >> >> >>
> > > >> >> >
> > > >> >> >
> > > >> >> > http://scalathus.blogspot.com
> > > >> >> >
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> cheer,
> > > >> >> nc
> > > >> >>
> > > >> >> http://scalathus.blogspot.com
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> cheer,
> > > >> nc
> > > >>
> > > >> http://scalathus.blogspot.com
> > > >
> > > > --
> > > > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> > > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> > > >
> > >
> > >
> > >
> > > --
> > > cheer,
> > > nc
> > >
> > > http://scalathus.blogspot.com
> > >
> >
> >
> >
> > --
> > Daniel C. Sobral
> >
> > I travel to the future all the time.
>

On Thu, Apr 22, 2010 at 2:32 PM, Dennis Haupt wrote:
> google has proof:
> http://www.drmaciver.com/2008/06/scala-arrays/
>
> scala always tries to use primitive arrays if possible.

That is for 2.7.7. The approach is quite different in 2.8.0:

http://www.scala-lang.org/sid/7

Best,
Ismael