Wann kommt neues OpenGL?

[KXII]

du hast geschrieben:

"

held_leben = 0;

und

"held.leben = 0;"

und

"held.stirb();"

liegt doch nur in der schreibweise.

Nein. Das hast du eben nicht verstanden. Die Schreibweise ist völlig egal. Es
geht einzig und allein um die Semantik.

"

du beschränkst wieder OO-programmierung auf kleinigkeiten. die semantik ist in jeder sprache unterschiedlich und die syntax ist vollkommen irrelevant. es kommt bei oo programmierung nicht darauf an, wie man die funktionalität hinschreibt, oder wie das, was hingeschrieben wurde zu deuten ist. ob man "stirb()" schreibt oder "leben=0", es hat keinen einfluss darauf, ob man nun oo programmiert oder nicht, denn sowas ist in einer strukturierten sprache möglch, oder auch in einer oo oder auch selbst in assembler (wie auch immer man diese sprachtyp bezeichnet). mann kann mit assembler eine funktion schreiben die "stirb" heisst, man kann aber auch eine funktion schreiben die "setleben" heisst, und nur weil man "stirb" benutzt heisst das noch lange nicht das die eigentliche programmierweise des ganzen programms objektorientiert ist. es kommt auf die relativen beziehungen von code und daten an, und wenn diese so angeordnet sind, das sie gruppen bilden, und funktionalität kapseln, dann spricht man von einer objekt-orientierten weise, eben weil man "objekte" als sortierkriterium genommen hat und nicht die reine strukturierung. man kann ja schliesslich auch mit assembler oo programmieren, nur man sieht das nicht so deutlich wie in hochsprachen. es mag zwar sein, das ein "stirb" schöner aussieht und in bezug auf die reale welt besser zu verstehen ist, es hat aber keinen einfluss auf die art der programmierweise. man darf oo auch nicht so "humanisiert" betrachten und alles was man programmiert aus unserer realen welt ableiten. das macht vielleicht oft sinn, es ist aber nicht immer möglich und ist auch nicht zwingend nur damit man oo programmiert.

ich sehe es so, und ich kann auch nicht erkennen wo mein denkfehler liegen sollte. falls die klassische informatik objektorientierung anders definiert hat, dann wird es halt zeit für eine neue definition. da bin ich mir sicher. ich kann und will mich auf jeden fall nicht an die alten, klassischen definitionen halten!

deshalb würde ich sagen: jedem seine meinung!

[Killing me Softly]

In der guten alten prozeduralen Zeit gab es auf der einen Seite die dummen Daten und auf der anderen Seite die schlauen Funktionen, die mit den Daten irgendetwas gemacht haben. Viele sehen in der OO nix weiter, als eine Möglichkeit, besagte Daten und Funktionen in Gruppen zu ordnen. Objektorientiertheit hat aber nix mit der sinnvollen Gruppierung von Funktionen und Variablen zu tun.
Ein Objekt hat keine Variablen und Funktionen sondern es hat Eigenschaften und besitzt ein Verhalten. Rein technisch gesehen ist das zwar das gleiche, vom gedanklichen Ansatz aber zwei vollkommen verschiedene Dinge.
Ob ich nun 'held.leben = 0;' oder 'held.set_leben(0);' schreibe, ist vollkommen Banane. In beiden Fällen setzte ich eine Eigenschaft des Objektes. held.sterben() ist allerdings ein Verhalten und es ist Sache des Objektes und nicht des Aufrufers, welche Auswirkungen dieses Verhalten hat. Im einfachsten Falle fällt unser Held tot um. Genauso gut könnte er aber auch zum Zombie mutieren. Das Verhalten kann auch von Objekt zu Objekt unterschiedlich sein.

Für alle, die zwischen 'held.leben = 0;' und 'held.sirb()' nur eine unterschiedliche Schreibweise erkennen empfehle ich mal die Lektüre "Objektorientierte Programmierung von Peter Coad, Jill Nicola"

[Sgt. Nukem]

Original erstellt von <Killing me Softly>:
Ob ich nun 'held.leben = 0;' oder 'held.set_leben(0);' schreibe, ist vollkommen Banane. In beiden Fällen setzte ich eine Eigenschaft des Objektes. held.sterben() ist allerdings ein Verhalten und es ist Sache des Objektes und nicht des Aufrufers, welche Auswirkungen dieses Verhalten hat. Im einfachsten Falle fällt unser Held tot um. Genauso gut könnte er aber auch zum Zombie mutieren. Das Verhalten kann auch von Objekt zu Objekt unterschiedlich sein.

Gut. Aber das Objekt könnte ja bei seiner Instanziierung auch einen eigenen Thread aufgemacht haben, und damit die ganze Zeit checken, ob leben == 0 ist, und wenn ja, DANN zu einem Zombie mutieren, oder einem Werwolf, oder Pamela Anderson...!

[KXII]

@unregistrierter

lies du deine lektüren. ich benutze mein gehirn.

[quadratwurzelsalat]

helium hat recht.

ich habs gerade mal durchgerechnet!!!

[Sgt. Nukem]

Muahahahahaha!! :p

[Helium]

<Killing me Softly> hat die ganz offensichtlich die objektorientierte Programmierung an sich verstanden und weis deren Vorteile zu nutzen, wärend KXII OO nur als eine Art Sprachfeature sieht und im Grunde nix damit anfangen kann. Das heißt natürlich nicht, dass KXII schlechtere Programme schreibt, sondern nur, dass er Sie auf eine aus heutiger sicht leicht veralteten weise schreibt. Aber das soll uns nicht weiter stören.
Und wenn wir jetzt nicht wieder zum Originalthema zurückfinden sollte das Thema bitte vom Moderator geschlossen werden.

[KXII]

@helium

das ist eindeutig eine beleidigung.

wenn hier jemand nicht versteht was objekt-ORIENTIERT heisst, dann du. und ich kann sehr wohl was damit anfangen. und ich glaube auch nicht dass ich meine programme auf eine veraltete weise schreibe. ich habe mindestens 10 argumente warum deine version schwachsinnig und falsch ist. ich habe aber keine lust sie dir darzustellen.

um es auf den punkt zu bringen:

meine darstellung bezieht sich auf OO im ALLGEMEINEN sinne. deine darstellung bezieht sich nur auf einen ganz, ganz kleinen bereich, der oo programmierung zu mehr ausdruck verhelfen KANN, aber absolut nichts mit dem GRUNDKONZEPT zu tun hat. oder willst du etwa sagen, das wenn man auch nur eine einzige funktion hat, die einen parameter hat, man nicht mehr oo programmiert? was ist denn wenn es ein onjekt gibt, das so etwas wie "stirb()" gar nicht kennt, oder bei dem nur ein "stirn(3)" sinn macht. dann wäre ja nach deiner defnition dieses objekt nicht mehr oo programmiert. aber das ist doch totaler schwachsinn. bevor du hier nochmal postest, dann bring erst mal deine definition von ALLGEMEINER oop und schwafel hier keinen scheiss, der obendrein auch noch falsch ist!

[kubikwurzelsuppe]

stimmt. KXII hat recht. oop geht viel weiter als nur auf die schreibweise von funktionen beschränkt. eine solche schreibweise macht oop deutlicher, aber es ist kein konstituierendes element. ich glaube auch das das beispiel von helium zu einfach gewählt ist. das was KXII gesagt hat passt ganz gut. was passiert denn wenn das objekt keine funktion "stirb" hat, sondern nur eine funktion "stirb(long,long,float)" einfach weil das so ist, und es anders keinen sinn macht. ist es dann nicht mehr objektorientiert programmiert, nur weil die funktion andere parameter hat? wo liegt da genau die grenze? gibt es da überhaupt eine grenze? und wer legt sie fest? wenn jemand das sterben von objekten anders sieht oder anders definiert, dann soll er es auch so programmieren! ist es dann aber nicht mehr objektorientiert programmiert nur weil er es anders gemacht hat als mit deiner vsersion helium? ich glaube wenn man so "eng" versucht objektorientierteprogrammierung zu beschreiben, dann wird das ganze sehr diffus!

[xZumWürfel]

KXII hat recht!!!
ich habs grad mal durchgerechnet!!!
es stimmt wirklich!!

[MEISTER DER MNEMONICS]

@Killing me Softly

Objektorientiertheit hat aber nix mit der sinnvollen Gruppierung von Funktionen und Variablen zu tun

AUTSCH!

...Ein Objekt hat keine Variablen und Funktionen sondern es hat Eigenschaften und besitzt ein Verhalten

also wenn ein objekt keine variablen und funktionen hat, dann bezieht sich deine sichtweise von objekten lediglich auf REALEXISTIERENDE objekte. da stimmt das natürlich und ich verstehe auch ganz ganu was du damit meinst. aber es gibt auch sowas wie abtrakte objekte, die mit der realen welt nicht zu vereinbaren sind. wie sollen diese denn aufgebaut sein, wenn sie nur eigenschaften und verhalten haben? das ist wie eine lehre hülle. etwas ohne kern. "eigenschaften" ist doch nur ein anderes wort für "variablen" und "verhalten" ein anderes wort für "methoden" (um nicht zu sagen funktionen). es gibt auch objekte die nur aus variablen bestehen, was ist denn dann mit denen? ein punkt zum beispiel.

class CPoint
{
public:
  long X;
  long Y;
};

ist das für dich ein objekt? ist das objekt-orientiert-programmiert? ich würde sagen ja. auch wenn es so alleine erst mal nichts anderes als eine datenstruktur ist. aber man kann dem objekt ja noch verhaltensweisen bzw. methoden hinzufügen. ist es dann wichtig wie diese methoden aussehen, nur damit es IMMER noch objekt-orientiert ist?

//das ist also objekt-orientiert?

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(void);
};

//das ist nicht mehr objekt-orientiert?

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(long);
};

//das ist objekt-orientiert?

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(void);
  void auferstehe(void);
};

//das nicht mehr objekt-orientiert?

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(void);
  void auferstehe(long);
};

//das ist dann bestimmt öbszön

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(long, long, long, long);
  void auferstehe(long, long, long, long);
};

[Saugie]

Original erstellt von KXII:
**@unregistrierter

lies du deine lektüren. ich benutze mein gehirn.**

Du denkst dir deine Definition von OOP selber aus und ein andere list es in einem Buch. Und du glaubst, dass das was du hier erzählst richtig ist?

Also IMO klingt das was killing me softly gesagt hat ganz vernünftig, hab aber, wie immer, keine Ahnung.

[KXII]

@Saugie

ich habe mir die definition von oop nicht ausgedacht!

ich habe früher auch einmal mit büchern angefangen und ich habe früher auch bücher über oop gelesen und ich kann mich auch noch sehr gut an die kinderbeispiele errinern, die oft genommen wurden um oop zu erklären. wer aber auch nur einen hauch mathematischer erfahrung hat, der weiss, was eine definition ist und was ein beispiel ist. sollen doch diejenigen, die sich an beispielen orientieren, weiter an diesen orientieren. ich sehe die problematik aber aus der sicht des rechners, so wie die struakturen intern tatsächlich sind und dort wird sehr deutlich, was es heisst, wenn man quellcode richtig strukturiert und richtig klassifiziert. und da ist die bedeutung von syntax (->semantik) als alleiniges kriterium einfach nicht ausreichend um objekte zu definieren.

ich programmiere jetzt schon über 9 jahre (ich bin 22 11/12=23, 23 - 9 = 14, habe also mit 14 angefangen), und ich habe, neben vielen anderen sprachen, vorwiegend mit assembler und c/c++ programmiererfahrung sammeln können. und ich kann ohne bedenken und mit viel selbstvertrauen sagen, dass ich soweit fortgeschritten bin, dass ich keine bücher mehr brauche, die mir die grundlagen des programmierens erklären! und genau diese erfahrungen lassen mich sehr wohl wissen was es heisst, wenn man den aufbau von quellcode an objekten orientiert. man kann die definition natürlich auch noch weiter ausbauen, aber der grundgedanke, der gleibt immer gleich. ich bin mir ganz sicher, daß das was ich sage nicht frei erfunden ist, sondern sich aus erfahrung herauskristalisiert hat und offensichtlich ist.

so, jetzt ist aber gut.

soll mich doch der teufel holen!

[Nachtrag des Teufel]

@helium

wenn "dingsda.setLeben(0);" nicht objektorientiert ist, was ist es denn dann?

[volkard]

Original erstellt von KXII:
es kommt bei oo programmierung nicht darauf an, wie man die funktionalität hinschreibt, oder wie das, was hingeschrieben wurde zu deuten ist. ob man "stirb()" schreibt oder "leben=0", es hat keinen einfluss darauf, ob man nun oo programmiert oder nicht, denn sowas ist in einer strukturierten sprache möglch, oder auch in einer oo oder auch selbst in assembler (wie auch immer man diese sprachtyp bezeichnet). mann kann mit assembler eine funktion schreiben die "stirb" heisst, man kann aber auch eine funktion schreiben die "setleben" heisst, und nur weil man "stirb" benutzt heisst das noch lange nicht das die eigentliche programmierweise des ganzen programms objektorientiert ist. es kommt auf die relativen beziehungen von code und daten an, und wenn diese so angeordnet sind, das sie gruppen bilden, und funktionalität kapseln, dann spricht man von einer objekt-orientierten weise, eben weil man "objekte" als sortierkriterium genommen hat und nicht die reine strukturierung. man kann ja schliesslich auch mit assembler oo programmieren, nur man sieht das nicht so deutlich wie in hochsprachen. es mag zwar sein, das ein "stirb" schöner aussieht und in bezug auf die reale welt besser zu verstehen ist, es hat aber keinen einfluss auf die art der programmierweise. man darf oo auch nicht so "humanisiert" betrachten und alles was man programmiert aus unserer realen welt ableiten. das macht vielleicht oft sinn, es ist aber nicht immer möglich und ist auch nicht zwingend nur damit man oo programmiert.

jo.
(und auf die erwähnte offizielle definioon von oo bin ich ja sehr gespannt.)

[ Dieser Beitrag wurde am 30.06.2003 um 01:52 Uhr von volkard editiert. ]

[Gregor]

Da: http://www.galileocomputing.de/glossar/gp/anzeige-8975/FirstLetter-O

Programmierung, die nicht wie in der klassischen strukturierten Programmierung Algorithmen und Datenstrukturen getrennt voneinander entwirft, sondern von Objekten ausgeht, die beides in sich vereinen.

Stimmt also im Prinzip mit dem Text von KXII überein.

BTW: Lustig: KXII will objektorientiert ohne die OO-Sprachfeatures programmieren und ich nutze die Features, programmiere aber nach der obigen Definition alles andere als objektorientiert.

[ Dieser Beitrag wurde am 30.06.2003 um 03:13 Uhr von Gregor editiert. ]

[Sgt. Nukem]

Original erstellt von <kubikwurzelsuppe>:
stimmt. KXII hat recht. oop geht viel weiter [...] sehr diffus!

Kann'et sein daß Du keine Ahnung hast und Dich hier nur profilieren willst?? :p

Original erstellt von <xZumWürfel>:
KXII hat recht!!!
ich habs grad mal durchgerechnet!!!
es stimmt wirklich!!

Scheiße, den Gag wollte ich g'rade machen...

Original erstellt von <MEISTER DER MNEMONICS>:
**@Killing me Softly

[qb]Objektorientiertheit hat aber nix mit der sinnvollen Gruppierung von Funktionen und Variablen zu tun**

AUTSCH![/QB]

Das muß in der Tat weher tun als meine Zahnschmerzen...! (...und das heißt schon was!!) :o

[qb]...Ein Objekt hat keine Variablen und Funktionen sondern es hat Eigenschaften und besitzt ein Verhalten

also wenn ein objekt keine variablen und funktionen hat, dann bezieht sich deine sichtweise von objekten lediglich auf REALEXISTIERENDE objekte. da stimmt das natürlich und ich verstehe [...] [/QB]

Natürlich kann ein Objekt auch NUR "Eigenschaften" (Member-Variablen) oder NUR "Verhalten" (Member-Methoden) haben...!
Ich denke mal, das meinte er auch so...
Natürlich kann ich nicht immer 1:1 Objekte (besser: Dinge) der realen Welt als Objekttypen abbilden...

Original erstellt von KXII:
@Saugie
ich sehe die problematik aber aus der sicht des rechners, so wie die struakturen intern tatsächlich sind und dort wird sehr deutlich, was es heisst, wenn man quellcode richtig strukturiert und richtig klassifiziert. und da ist die bedeutung von syntax (->semantik) als alleiniges kriterium einfach nicht ausreichend um objekte zu definieren.

Ähhh... also diese "Objektorientierung" dient eigentlich *NUR* dem Menschen, dem Programmierer, der das Dingen codet, da Menschen nun mal von Natur aus in "Objekten" denken...
Dem Computer is' dat scheißegal! Du könntest auch 1 Millionen Befehle an Quellcode in eine Zeile quetschen oder besagtes "for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);" compilieren, da spielt der sich nich' am Pipimann für...

[...] und genau diese erfahrungen lassen mich sehr wohl wissen was es heisst, wenn man den aufbau von quellcode an objekten orientiert. man kann die definition natürlich auch noch weiter ausbauen, aber der grundgedanke, der gleibt immer gleich. ich bin mir ganz sicher, daß das was ich sage nicht frei erfunden ist, sondern sich aus erfahrung herauskristalisiert hat und offensichtlich ist.

Jo, das seh' ich auch so.
Bei großen Programmier-Vorhaben ist die gute alte strukturierte Programmierung einfach fehl am Platze. Zu fehleranfällig, zu unrobust, ...
Für kleinere Sachen natürlich noch immer nicht ersetzbar.

Ein ähnliches Verhalten durchläuft ja jetzt auch die Shadersprache (wenn auch viel schneller und unspektakulärer): Eigentlich waren's 'n Haufen von ASM-Befehle, und um's dem Menschen verständlicher zu machen, wurden HighLevel-Sprachen wie Cg oder HLSL entworfen... (hat jetzt nix direkt mit OO zu tun)

Original erstellt von Gregor:
BTW: Lustig: KXII will objektorientiert ohne die OO-Sprachfeatures programmieren und ich nutze die Features, programmiere aber nach der obigen Definition alles andere als objektorientiert.

Was sind denn die "OO-Sprachfeatures"?? Naja, Vererbung wird er wohl auch benutzen, etc. ...
Du nutzt Vererbung und Polymorphie OHNE OO?? Wie'n das??

[KXII]

@sgt. nukem

Ähhh... also diese "Objektorientierung" dient eigentlich *NUR* dem Menschen, dem Programmierer, der das Dingen codet, da Menschen nun mal von Natur aus in "Objekten" denken...
Dem Computer is' dat scheißegal! Du könntest auch 1 Millionen Befehle an Quellcode in eine Zeile quetschen oder besagtes "for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);" compilieren, da spielt der sich nich' am Pipimann für...

so wie du es darstellst war es von mir nicht gemeint. aber eigentlich müsstest du dir das doch denken können. es sollte nur verdeutlichen, das ich es von "unten" her betrachte, und mir eben diese sichtweise die beudetung von oop klarer macht. ich wollte NICHT sagen, das es einzig und allein nur drauf ankommt und sonst nichts. das wäre dann ja falsch.

[Gregor]

Original erstellt von Sgt. Nukem:
**
Du nutzt Vererbung und Polymorphie OHNE OO?? Wie'n das?? **

Das bezog sich auf "Datenstrukturen und Algorithmen in Objekten vereint".

An vielen Stellen trenne ich Datenstrukturen und Algorithmen ganz explizit. Die Algorithmen sind dann selbst Objekte und die entsprechenden Klassen liegen weder in der gleichen Datei noch im gleichen Verzeichnis. Naja: Das ist wohl ne Frage der Sichtweise. Man kann es trotzdem als OOP ansehen.

[ Dieser Beitrag wurde am 30.06.2003 um 13:26 Uhr von Gregor editiert. ]

[Helium]

meine darstellung bezieht sich auf OO im ALLGEMEINEN sinne. deine darstellung bezieht sich nur auf einen ganz, ganz kleinen bereich, der oo programmierung zu mehr ausdruck verhelfen KANN, aber absolut nichts mit dem GRUNDKONZEPT zu tun hat. oder willst du etwa sagen, das wenn man auch nur eine einzige funktion hat, die einen parameter hat, man nicht mehr oo programmiert? was ist denn wenn es ein onjekt gibt, das so etwas wie "stirb()" gar nicht kennt, oder bei dem nur ein "stirn(3)" sinn macht. dann wäre ja nach deiner defnition dieses objekt nicht mehr oo programmiert. aber das ist doch totaler schwachsinn. bevor du hier nochmal postest, dann bring erst mal deine definition von ALLGEMEINER oop und schwafel hier keinen scheiss, der obendrein auch noch falsch ist!

Die Anzahl der Parameter hat absolut nichts mit oo zu tun, auch wenn meine Erfahrung zeigt (nicht nur mit eigenem Quellcode), dass in der objektorientierten Programmierung viele Funktionen wenige Parameter besitzen. Funktionen ohne Parameter kommen in der strukturierten Programmierung nur äußerst selten vor.

also wenn ein objekt keine variablen und funktionen hat, dann bezieht sich deine sichtweise von objekten lediglich auf REALEXISTIERENDE objekte. da stimmt das natürlich und ich verstehe auch ganz ganu was du damit meinst. aber es gibt auch sowas wie abtrakte objekte, die mit der realen welt nicht zu vereinbaren sind. wie sollen diese denn aufgebaut sein, wenn sie nur eigenschaften und verhalten haben? das ist wie eine lehre hülle. etwas ohne kern. "eigenschaften" ist doch nur ein anderes wort für "variablen" und "verhalten" ein anderes wort für "methoden" (um nicht zu sagen funktionen). es gibt auch objekte die nur aus variablen bestehen, was ist denn dann mit denen? ein punkt zum beispiel.

In einer doppelt verketete Liste hat jedes Element einen Vorgänger und einen Nachfolger. Das sind Eigenschaften. Wenn du mir eine realexistierende doppelt verkettete Liste besorgen kannst bekommst du 100€ von mir.

wenn "dingsda.setLeben(0);" nicht objektorientiert ist, was ist es denn dann?

Es mag sein, das dingsda.setLeben(0) objektorientiert ist. Ich kenne die definition von Dingsda nicht, weiß vor allem nicht, was ein dingsda ist. Tut mir leid. Falls dingsa ein Lebewesen repräsentieren soll, ist es falsch. Und daruaf willst du ja hinaus.

Beispiel: Ich habe letztens (ist schon was her) eine physikalische Simmulation geschrieben. Es ging Um Gravitation. Mehrere Planeten sollten um eine Sonne kreisen.
Ich denke wir sind uns einig, dass wir wärend der OOA darauf kommen, dass es irgendwo in unserem System eine Klasse Planet geben wird. Die Klasse besaß nun ein Objekt position, welches vom Typ Punkt war. Das hätte dein Planet vermutlich auch gehabt. Was unsere Planeten unterscheidet ist folgendes: Dein Planet, so vermute ich, besitzt die Methoden set_position() und get_position(). Meiner besaß zwar auch ein get_position(), aber kein set_position(), was, wenn ich dich richtig einschätze, ür dich völlig absurd ist. Aber man kann einen Planeten nicht einfach durch die gegend beamen (selbst bei Star Trek hat das noch keiner geschaft). set_position() kann somit niemals eine eigenschaft von Planet sein.
Und siehe da trotzdem funktioniert meine Simulation perfekt. Falls du jetzt denkst, es gäbe etwas vergleichbares zu set_position() nur unter anderem Namen, dann irrst du dich. Es gab nur die dinge, die ein echter Planet auch kann, bzw. hat. Und das ist kein Wunder. In der Natur funktionier es ja auch.

Die Kunst bei der OOP, wenn es denn eine ist, ist es die Natur der wenn auch föllig abstrakten Objekte zu verstehen.

Und nochwas OOP wurde nicht für den Computer entwickelt worden, sondern für den Menschen. Der Computer käme mit Assembler wesentlich besser klar, auch wenn die Mnemonics immer noch zu umständlich sind. So muss er es sich vorher alles übersetzen.

Nur für KXXI:
Da du es ja so toll fandest, mit dem Alter, mit welchem du angefangen hast zu programmieren, zu protzen: Ich hab mit 11 meine ersten Programme geschrieben. Sorry.