Skript mit Dateiname als Variable

[Michael E.]

In Ruby kann man es so machen (geht bestimmt besser, aber funktioniert):

files = Dir.entries('.').reject { |name| File.directory?(name) or File.extname(name) != '.nc' }
for file in files
	lines = IO.readlines file
	File.open(file, 'w') do |out|
		out.write "%PM\n"
		out.write lines[1].chomp
		out.write " (#{File.basename(file, '.nc')})\n"
		for line in lines[2..-1]
			out.write line
		end
	end
end

[!rr!rr_.]

warum die Technik von heute benutzen, wenn man auch die von morgen haben kann ?

Smalltalk:

files := FileDirectory default 
	fileNamesMatching: '*.nc'.
files do: [ :oldName |
	| lines name newFile newName |
	lines := (StandardFileStream 
		oldFileNamed: oldName) 
			readOnly contents lines.
	name := FileDirectory 
		baseNameFor: oldName.
	newName := name, '.nc.new'.
	newFile := StandardFileStream 
		forceNewFileNamed: newName.
	newFile 
		nextPutAll: '%PM'; 
		crlf.
	lines at: 2 
		put: (lines at: 2), '  (' asString, name, ')' asString.
	lines allButFirstDo: [ :line |
		newFile 
			nextPutAll: line; 
			crlf ] ].

[Michael E.]

!rr!rr_. schrieb:

warum die Technik von heute benutzen, wenn man auch die von morgen haben kann ?

Smalltalk:

LOL. Smalltalk ist Anfang der 70er entstanden, war nie praktisch relevant und wird es auch nie sein.

[!rr!rr_.]

Smalltalk ist Anfang der 70er entstanden, war nie praktisch relevant und wird es auch nie sein.

Laß mich das mit zwei Einzeilern beantworten:

smalltalk (1972-1980):

1 to: 10 do: [ :n | 
    Transcript show: n asString, '.' ].

ruby (1993-):

1.upto(10) { | n | STDOUT.write print n, "." }

Smalltalk gehört gemeinsam mit Sprachen wie LISP, Algol, APL und Prolog zu den einflußreichsten Programmiersprachen überhaupt.

(außerdem fällt mir gerade auf, daß in der 5. zeile von unten die beiden #asString überflüssig sind.)

[Babblfish]

Ich denke nicht, dass dies Gegenstand dieses Threads ist.

@ Polarnacht, hoffe dir konnte mit den vorgeschlagenen Lösungen geholfen werden (ist nicht der Standard dass du hier fertige Codes bekommst... also schön Danke sagen :D)

Welche der Lösungen du verwendest bleibt wohl dir überlassen - wichtig ist dass du verstehst was du da ausführst.

Viel Glück jedenfalls!

[hustbaer]

!rr!rr_. schrieb:

Smalltalk gehört gemeinsam mit Sprachen wie LISP, Algol, APL und Prolog zu den einflußreichsten Programmiersprachen überhaupt.

Was nicht heisst dass es jemals praktisch relevant gewesen sein muss.

[!rr!rr_.]

Du willst uns auf den Arm nehmen, oder?

Smalltalk ist ebenso relevant wie die 5 Prinzipien der OOP ("alles ist ein Objekt" usw) - Smalltalk ist nämlich eine Modell-Implementation dieser Prinzipien.

Und davon gibt es nicht viele - mir fällt im Moment nur noch Self ein, der Prototypen-basierte "Neffe" von Smalltalk. Der erfüllt aber Prinzip #2 ("Jedes Objekt ist Instanz einer Klasse") nicht.

[!rr!rr_.]

... was im Falle von Self selbstverständlich kein Mangel, sondern ein Feature ist: Prototypenbasierte statt Klassenbasierte OOP.

[hustbaer]

Vermutlich definierst du "praktisch Relevant" anders als ich.

Wenn ich schreibe (sinngemäss) "hat viel Einfluss gehabt" heisst das nicht "war praktisch relevant", dann meine ich mit dem "praktisch relevant" Teil: wurde es ausserhalb der akademischen Welt "in der Praxis" von vielen Leuten eingesetzt?

Was konkret Smalltalk angeht:

Möglich dass Smalltalk viel in der Industrie eingesetzt wurde, aber ich bezweifle es. Zumindest wenn wir "viel" als "annähernd so viel wie C/BCPL/..." definieren. Mag sein dass ich mich da täusche, aber egal, darum geht es (mir) nicht wirklich.

D.h. man kann (nach meiner Definition von "praktisch relevant") auch nicht behapten dass irgendwas "praktisch relevant" (gewesen) sein muss, nur weil es viele Dinge die heute durchaus "praktisch relevant" sind beeinflusst hat.

Das wollte ich damit sagen. Mehr nicht

ps: "alles ist ein Objekt" ist ein "Prinzip der OOP" das ich nicht anerkenne.

[!rr!rr_.]

sollte man diese Diskussion nicht in einen getrennten Thread auslagern? das gehört wirklich nicht mehr zur eigentlichen Frage.

hustbaer schrieb:

ps: "alles ist ein Objekt" ist ein "Prinzip der OOP" das ich nicht anerkenne.

Object-Message-Passing ist eine zentrale Eigenschaft von OOP - da sind wir wohl einig. In einem System, in dem nicht alles Objekt ist, gibt es demnach Funktionalität, die nicht durch Object-Message-Passing erreichbar ist.

Außerdem ist "alles ist ein Objekt" eines der 5, 6 oder 17 (je nach Quelle) Prinzipien, nach denen DIE Modell-Implementierung von OO (Smalltalk) gebaut ist.

hustbaer schrieb:

Wenn ich schreibe (sinngemäss) "hat viel Einfluss gehabt" heisst das nicht "war praktisch relevant",

Ideen und Prinzipien, die von aller Welt benutzt werden, sind doch praktisch relevant?

[hustbaer]

!rr!rr_. schrieb:

Object-Message-Passing ist eine zentrale Eigenschaft von OOP - da sind wir wohl einig. In einem System, in dem nicht alles Objekt ist, gibt es demnach Funktionalität, die nicht durch Object-Message-Passing erreichbar ist.

Funktionsaufrufe sind wichtig bei jeglicher Art der Programmierung.
Sie als "Object-Message-Passing" zu bezeichnen ändert daran nichts, und macht es auch nicht neu oder OOP-spezifisch.

Falls du damit Dynamic Dispatching oder "Multiple Dispatch" meinen solltest: nö, ist für OOP nicht nötig.

[!rr!rr_.]

Funktionsaufruf und Object-message passing ist nicht dasselbe (außer in Python vielleicht keine Ahnung)

Object-message passing:

7 raisedToInteger: 3.

eine spezielle Syntax für Funktionsaufrufe braucht es in Smalltalk nicht, wird ja alles durch object-message passing realisiert:

[ :x | x raisedToInteger: 3 ] value: 7.

[hustbaer]

Klar ist es das selbe. Andere Syntax vielleicht, aber wen interessiert schon die Syntax?

Falls du anderer Meinung bist: was soll bitte der konzeptionelle/semantische/... Unterschied sein?

[Shade Of Mine]

!rr!rr_. schrieb:

Funktionsaufruf und Object-message passing ist nicht dasselbe

Wo genau ist der unterschied zwischen
a.foo()
und
foo(&a)

?

[!rr!rr_.]

hm, du fragst wirklich, worin der Unterschied zwischen einem Methodenaufruf und einem Funktionsaufruf besteht ?

Das hängt, wie du weißt, sehr von der Sprache ab. In C++ sind das zwei völlig verschiedene Paar Schuhe, angefangen damit, daß Methoden auf Instanzvariablen des angesprochenen Objekts zugreifen könnnen usw. wogegen in foo(&a) das a nicht mal ein Objekt sein muß usw. aber das weißt Du doch ...

[Michael E.]

Was du aufzählst, sind syntaktische Unterschiede. Man hätte beim Design von C++ auch sagen können: Eine Methode m einer Instanz i ruft man mit m(&i, ...) statt i.m(...) auf. Was wäre der Unterschied? So kannst du BTW objektorientiert in C programmieren.

hustbaer schrieb:

Andere Syntax vielleicht, aber wen interessiert schon die Syntax?

Falls du anderer Meinung bist: was soll bitte der konzeptionelle/semantische/... Unterschied sein?

[!rr!rr_.]

ja, so kannst du eine Art OOP in Sprachen ohne Objektmodell simulieren. Vergleiche auch python's "self"-Parameter in den Methoden.

- was will uns das sagen ? Man kann auch forth in javascript simulieren, ist javascript deshalb eine concatenative language, oder was?

Der Unterschied zeigt sich spätestens dann, wenn du messages kaskadieren willst. Das geht mit echtem message passing einfach durch Aneinanderhängen der messages:

#(1 2 3) allButFirst allButLast printOn: Transcript.

ich finde, die Lesbarkeit des Gegenstücks ohne message passing ...

printOn(&Transcript, allButLast_Array(allButFirst_Array(add_Array(add_Array(&emptyArray,1),2),3))))

... fällt im Vergleich etwas ab

Aber auch Polymorphie stelle ich mir mit Funktions- (statt Methoden-)Aufrufen bei statischer Typisierung schwierig vor - schließlich muß das erste Argument (der Zeiger auf das "Objekt") ja einen Typ haben.

Drittens, wie ist das mit "state hiding"? Wer verbietet den Zugriff auf privates in einer solchen OO-Simulation?

[Michael E.]

!rr!rr_. schrieb:

Der Unterschied zeigt sich spätestens dann, wenn du messages kaskadieren willst. Das geht mit echtem message passing einfach durch Aneinanderhängen der messages:

#(1 2 3) allButFirst allButLast printOn: Transcript.

ich finde, die Lesbarkeit des Gegenstücks ohne message passing ...

printOn(&Transcript, allButLast_Array(allButFirst_Array(add_Array(add_Array(&emptyArray,1),2),3))))

... fällt im Vergleich etwas ab

Das ist doch nur Syntaxzucker. Ich will hustbaer nicht nochmal zitieren.

Aber auch Polymorphie stelle ich mir mit Funktions- (statt Methoden-)Aufrufen bei statischer Typisierung schwierig vor - schließlich muß das erste Argument (der Zeiger auf das "Objekt") ja einen Typ haben.

Wo genau ist das Problem? Bei virtuellen Funktionen erstellst du dir ne vtable.

Drittens, wie ist das mit "state hiding"? Wer verbietet den Zugriff auf privates in einer solchen OO-Simulation?

Das ist ne ganz andere Baustelle.

[!rr!rr_.]

Michael E. schrieb:

Das ist doch nur Syntaxzucker.

das ist ja interessant.

- Dann kannst du sicher mal den folgenden einfachen
Smalltalk-Ausdruck in gleichwertige C-Funktionsaufrufe umwandeln?

Object class class isMemberOf: Metaclass class.

[!rr!rr_.]

oder formuliere das mal mit C und Funktionsaufrufen:

o := Object new.
Object compile: 'foo ^123'.
o foo.

(hierbei wird dem Object o zu dessen Lebenszeit eine neue Fähigkeit hinzugefügt und abgerufen - ohne das Objekt zu zerstören oder neu zu erzeugen)