Ein tuple, dessen Element(e) auf diverse strings (???) verweist. Also etwas in der Art
Code: Alles auswählen
(refer to 'h', refer to 'a', refer to 'l', refer to 'l', refer to 'o')
Code: Alles auswählen
(refer to 'h', refer to 'a', refer to 'l', refer to 'l', refer to 'o')
Ganz so abwegig ist der Gedanke nicht, ähnlich wird mit "Strings" und Listen ind Haskell verfahren. Aber ich empfehle auch einen Blick in den Code. Der ist nicht besonders lang und dort steht es ganz genau.cofi hat geschrieben:Wie kommst du denn auf den Gedanken, dass es ein Tuple sein sollte?
Andererseits ist es auch nicht so abwegig das Strings eigenständig sind, denn in C gab es diese ja schon als char*. Tuples sind da doch schon schwerer umzusetzen.EyDu hat geschrieben:Ganz so abwegig ist der Gedanke nicht, ähnlich wird mit "Strings" und Listen ind Haskell verfahren.
Nuja, ich würde es mal so sagen: Es existieren nun einmal die Namen "Tupel" und "String". Wozu sollte man das unterscheiden, wenn es keinen semantischen Unterschied gibt? :K Mir fielen da nur Kompatibilitätsgründe ein, die dann aber dokumentiert wären. Das alleine suggeriert zumindest schon mal die Unterschiedlichkeit.mutetella hat geschrieben: Ich möchte mich aber jetzt gar nicht so sehr auf 'tuple' oder 'nicht tuple' versteifen. Mit geht es darum, ob Python 'intern' einen wirklichen Unterschied zwischen einem 'tuple' und einem 'string' macht.
Ich wollte mit meinem Hinweis nicht über die interne Struktur spekulieren, sonder andeuten, dass es auch andere Wege als den "Standardweg", welcher bei Python ganz offensichtlich eingeschlagen wurde, gibt. Als Gründe für eine Unterscheidung sehe ich vorallem Operationen, welche nicht auf beiden Strukturen Sinn ergeben und Performancegewinne. Von der Umsetzung sind Tupel genau so einfach wie Strings.Xynon1 hat geschrieben:Ich kann mich auch irren, aber der Code(python 2.7) sieht für mich schon sehr eigenständig aus.
Andererseits ist es auch nicht so abwegig das Strings eigenständig sind, denn in C gab es diese ja schon als char*. Tuples sind da doch schon schwerer umzusetzen.EyDu hat geschrieben:Ganz so abwegig ist der Gedanke nicht, ähnlich wird mit "Strings" und Listen ind Haskell verfahren.
Nun ja, weil sich ein string ähnlich wie ein tuple verhält und letztlich doch nur über mehr Methoden verfügt.cofi hat geschrieben:Wie kommst du denn auf den Gedanken, ...
Spätestens hier muss ich aussteigen und verweile in ehrfürchtigem Staunen...cofi hat geschrieben:Dann solltest du wohl in den Code schauen.
So schön sieht der C-Code nun auch wieder nicht ausmutetella hat geschrieben:...und verweile in ehrfürchtigem Staunen...
Das gilt aber ueblicherweise nicht fuer die hier genannten funktionalen Sprachen (Erlang koennte da ne Ausnahme sein, es vereint ja die Nachteile interpretierter & funktionaler Programmierung unnachahmlich... ). Da musst du schon explizite Summentypen definieren, einen impliziten "von allen" gibt's nicht. Tupel sind dann auch eher nicht, sondern listen - also cons-zellen mit Zeiger auf Kopf + Rest. Aber weil halt funktional, dann doch immutable, wie Python's Tupel...BlackJack hat geschrieben:@Xynon1: Wenn es einen "Obertyp" gibt, sehe ich da keine Probleme. Also zum Beispiel so etwas wie `object` wovon alles andere Untertypen sind. Andere Sprachen, ohne so eine feste Typhierarchie, haben dann zum Beispiel einen speziellen Platzhaltertypen der `Any` oder `Variant` oder so heisst. Gibt es zum Beispiel in einigen BASIC-Dialekten. Oder auch »Pointer auf "irgendein Ding"«, also so etwas wie ``void *`` in C.
Und warum tust du es dann immer?mutetella hat geschrieben:Hat man mir damals nicht gerade deshalb auch Python empfohlen, weil ich mir dann über solche Dinge keinen Kopf machen muss...?
Gut, ein Beispiel in wenigen Minuten zusammengeschrieben. Die untere Hälfte besteht nur aus Beispiel und syntaktischem Zucker, lediglich die Klasse ist wirklich interessant.Xynon1 hat geschrieben:Das streite ich auch gar nicht ab, nur das Tuples in einer statisch typisierten Sprache genauso "einfach" wie Strings umzusetzen sind, kann ich irgendwie nicht glauben. Ich möchte nicht behaupten das es schwer ist, aber ist es nicht etwas komplexer eine Sequenz mit unterschiedlichen Datentypen umzusetzen, als eine mit gleichen?
Wenn man möchte, kann man sich natürlich in unwichtigen Beispielen verfangen und dieses vollkommen überziehen Es ging um die prinzipielle Machbarkeit.cofi hat geschrieben:@EyDu:
Da waer ich jetzt vorsichtig, wie DasIch schon geschrieben hat, sind das da keine Tupel, sondern Listen. Und die vorrangige Eigenschaft der Haskell-Tupel ist, dass man da verschiedene Datentypen mischen kann.
Weil ich glaube, dass gerade beim Programmieren ein theoretisches Verständnis dessen, was Du ein Primitivum nennst sich letztlich in 'besserem' Code niederschlägt.cofi hat geschrieben:Und warum tust du es dann immer?
Was meinst Du damit: gegen eine definierte Semantik?cofi hat geschrieben:... oder ob man lieber gegen eine definierte Semantik programmiert.