---

Hej,

Hvad er ideen bag at have primitive typer + wrapper klasser til disse
proppet med statiske metoder? Hvorfor har man ikke bare lavet de primitive
typer til _rigtige_ objekter? Hastighedsårsager? Heap-allocation issues?

Venligst!

---

On 2006-09-20, Peter Wing Larsen <peterwing@mail.dk> wrote:
>
> Hvad er ideen bag at have primitive typer + wrapper klasser til disse
> proppet med statiske metoder? Hvorfor har man ikke bare lavet de primitive
> typer til _rigtige_ objekter? Hastighedsårsager? Heap-allocation issues?

http://www.artima.com/intv/gosling313.html

Bill Venners: Why are there primitive types in Java? Why wasn't
everything just an object?

James Gosling: Totally an efficiency thing. There are all kinds of
people who have built systems where ints and that are all objects. There
are a variety of ways to do that, and all of them have some pretty
serious problems. Some of them are just slow, because they allocate
memory for everything. Some of them try to do objects where sometimes
they are objects, sometimes they are not (which is what the standard
LISP system did), and then things get really weird. It kind of works,
but it's strange.

Just making it such that there are primitive and objects, and they're
just different. You solve a whole lot of problems.

--
Andreas

---

Andreas Plesner Jacobsen wrote:
> On 2006-09-20, Peter Wing Larsen <peterwing@mail.dk> wrote:
>> Hvad er ideen bag at have primitive typer + wrapper klasser til disse
>> proppet med statiske metoder? Hvorfor har man ikke bare lavet de primitive
>> typer til _rigtige_ objekter? Hastighedsårsager? Heap-allocation issues?
>
> http://www.artima.com/intv/gosling313.html
>
> Bill Venners: Why are there primitive types in Java? Why wasn't
> everything just an object?
>
> James Gosling: Totally an efficiency thing. There are all kinds of
> people who have built systems where ints and that are all objects. There
> are a variety of ways to do that, and all of them have some pretty
> serious problems. Some of them are just slow, because they allocate
> memory for everything. Some of them try to do objects where sometimes
> they are objects, sometimes they are not (which is what the standard
> LISP system did), and then things get really weird. It kind of works,
> but it's strange.
>
> Just making it such that there are primitive and objects, and they're
> just different. You solve a whole lot of problems.

C# synes at have fundet en udmærket løsning.

Og med auto boxing/unboxing i Java 1.5 fungerer Java lidt
på samme måde, bare mere klodset lavet.

Arne

---

"Arne Vajhøj" <arne@vajhoej.dk> wrote in message
news:9gkQg.71$2g4.55@dukeread09...
> Andreas Plesner Jacobsen wrote:
>> On 2006-09-20, Peter Wing Larsen <peterwing@mail.dk> wrote:
>>> Hvad er ideen bag at have primitive typer + wrapper klasser til disse
>>> proppet med statiske metoder? Hvorfor har man ikke bare lavet de
>>> primitive typer til _rigtige_ objekter? Hastighedsårsager?
>>> Heap-allocation issues?
>>
>> http://www.artima.com/intv/gosling313.html
[snip]

> C# synes at have fundet en udmærket løsning.
>
> Og med auto boxing/unboxing i Java 1.5 fungerer Java lidt
> på samme måde, bare mere klodset lavet.

Vil du uddybe?

---

Peter Wing Larsen wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> wrote in message
> news:9gkQg.71$2g4.55@dukeread09...
>> C# synes at have fundet en udmærket løsning.
>>
>> Og med auto boxing/unboxing i Java 1.5 fungerer Java lidt
>> på samme måde, bare mere klodset lavet.
>
> Vil du uddybe?

C# har et objekt hieraki:

Object
ValueType
int, double etc.

Det gør at en int faktisk er et Object.

Alle typer der arver fra ValueType får så lidt special
behandling for at få dem til at opføre sig "normalt".

Der er et vist overhead når data skal flyttes
mellem heap og stack (auto boxing/unboxing).

Men det har Java jo også med samme operation fra og
med Java 1.5.

Så synes jeg jo lige så godt at man kunne have taget
skridtet fuldtud og droppet wrapper klasserne og ladet de
simple data typer arve fra object.

Det havde man måske også gjordt hvis man skulle designe
Java fra scratch idag.

Arne

---

"Andreas Plesner Jacobsen" <apj@daarligstil.dk> wrote in message
news:slrneh3802.4lu.apj@irq.dk...
> On 2006-09-20, Peter Wing Larsen <peterwing@mail.dk> wrote:
>>
>> Hvad er ideen bag at have primitive typer + wrapper klasser til disse
>> proppet med statiske metoder? Hvorfor har man ikke bare lavet de
>> primitive
>> typer til _rigtige_ objekter? Hastighedsårsager? Heap-allocation issues?
>
> http://www.artima.com/intv/gosling313.html
>
> Bill Venners: Why are there primitive types in Java? Why wasn't
> everything just an object?
[snip]

Tak for henvisningen. Gad vide hvor meget run-time overhead det i
virkeligheden vil give at have primitive typer som objekter. Om ikke andet
kunne meget af det vel forbedres, hvis compileren var smart.

---

On Thu, 21 Sep 2006 07:15:50 +0200, Peter Wing Larsen wrote:

>
> Tak for henvisningen. Gad vide hvor meget run-time overhead det i
> virkeligheden vil give at have primitive typer som objekter. Om ikke andet
> kunne meget af det vel forbedres, hvis compileren var smart.
Du kan jo prøve, at lave et beregningstungt program med henholdsvis
primitive datatyper eller objekter, og så foretage måling på
eksekveringstiden.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen wrote:
> On Thu, 21 Sep 2006 07:15:50 +0200, Peter Wing Larsen wrote:
>> Tak for henvisningen. Gad vide hvor meget run-time overhead det i
>> virkeligheden vil give at have primitive typer som objekter. Om ikke andet
>> kunne meget af det vel forbedres, hvis compileren var smart.

> Du kan jo prøve, at lave et beregningstungt program med henholdsvis
> primitive datatyper eller objekter, og så foretage måling på
> eksekveringstiden.

I et sprog hvor simple data typer ikke er objekter (som Java)
vil simple data typer være hurtigere end objekter p.g.a.
object creation og GC overhead.

Men der er tilsyneladende ikke noget overhead ved at have
simple data typer være objekter. Ihvertfald er tal knusning
i C# lige så hurtigt som i Java.

Arne

---

Arne Vajhøj <arne@vajhoej.dk> writes:

> Men der er tilsyneladende ikke noget overhead ved at have
> simple data typer være objekter. Ihvertfald er tal knusning
> i C# lige så hurtigt som i Java.

De simple typer (int, boolean, etc.) er ikke objekter i C#. De er
"struct"'er, som til forskel fra objekter ikke har en identitet. Det
betyder at man ikke behøver bekymre sig om hvorvidt en instans af 42
er forskellig fra en anden.
(Forvirrende nok er struct'er typemæssigt en specialisering af typen
Object. Der burde de nok have haft en fælles supertype, fx kaldet
"Value")

I den virtuelle maskine er der sandsynligvis en bunke optimeringer
på netop de indbyggede numeriske typer.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

"Lasse Reichstein Nielsen" <lrn@hotpop.com> wrote in message
news:y7sb4xmu.fsf@hotpop.com...
> Arne Vajhøj <arne@vajhoej.dk> writes:
>
>> Men der er tilsyneladende ikke noget overhead ved at have
>> simple data typer være objekter. Ihvertfald er tal knusning
>> i C# lige så hurtigt som i Java.
>
> De simple typer (int, boolean, etc.) er ikke objekter i C#. De er
> "struct"'er, som til forskel fra objekter ikke har en identitet. Det
> betyder at man ikke behøver bekymre sig om hvorvidt en instans af 42
> er forskellig fra en anden.
> (Forvirrende nok er struct'er typemæssigt en specialisering af typen
> Object. Der burde de nok have haft en fælles supertype, fx kaldet
> "Value")

Hvad så med

..NET Framework Class Library
ValueType Class
Provides the base class for value types.

---

Lasse Reichstein Nielsen wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>> Men der er tilsyneladende ikke noget overhead ved at have
>> simple data typer være objekter. Ihvertfald er tal knusning
>> i C# lige så hurtigt som i Java.
>
> De simple typer (int, boolean, etc.) er ikke objekter i C#. De er
> "struct"'er, som til forskel fra objekter ikke har en identitet.

Type mæssigt er int (som alle struct'er) en ValueType som er et object.

(intvariabel is object) returnerer true.

Det kalder jeg ihvertfald for at en int type er et object.

Men ja - man kalder ikke værdien af en value type for
et objekt i modsætning til en reference type som peger
på et objekt.

> (Forvirrende nok er struct'er typemæssigt en specialisering af typen
> Object. Der burde de nok have haft en fælles supertype, fx kaldet
> "Value")

Det har de. Den hedder ValueType.

Forvirringen er ikke så stor i praksis. Man bruge value type
om det som vi i java kalder simple data typer og reference type
om det vi i Java kalder for en objekt type.

Arne

---

"Peter Wing Larsen" <peterwing@mail.dk> writes:

> "Lasse Reichstein Nielsen" <lrn@hotpop.com> wrote in message
> news:y7sb4xmu.fsf@hotpop.com...

>> (Forvirrende nok er struct'er typemæssigt en specialisering af typen
>> Object. Der burde de nok have haft en fælles supertype, fx kaldet
>> "Value")
>
> Hvad så med
>
> .NET Framework Class Library
> ValueType Class
> Provides the base class for value types.

Den er netop under Object i typehierarkiet:

<URL:http://www.informit.com/content/images/chap13_0321169514/elementLinks/13fig02.gif>

(og "ValueType" er forresten et mere korrekt navn end "struct", som
blot er det keyword man bruger når man definerer bruger-definerede
værdityper, lige som "class" bruges til at definere klasser)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'