@classmethod ganz neu entdeckt (und Namespaces)

[birkenfeld]

Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.

Ich dachte, das warst du...

[poker]

Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.

Ich dachte, das warst du...

Ganze Sätze Herr Birkenfeld! Also, was meinst du? Kann dir nicht folgen.

edit: typos

[gerold]

Ich dachte, das warst du...

Hallo!

Um das aufzuklären: Die Aussage "Klasse nicht für Namespace nutzen" habe ich von BlackJack aufgeschnappt. Und da er einer von denen ist deren Meinung bei mir zählt, suche ich nach Alternativen.

Ich muss aber auch zugeben, dass ich nicht mehr lange suchen werde. Ich habe etwas dagegen, eine feine Sache gegen etwas Umständlicheres ohne Mehrwert zu tauschen. Und eine kleine Klasse mit 30 Zeilen ist mir im Hauptprogramm lieber als in einer eigens dafür angelegten Datei. Noch dazu muss ich dann extra dafür ein Projekt in der IDE anlegen (um mehrere Dateien zu verwalten) und jedes mal das Modul öffnen, wenn ich nachsehen muss was sich darin befindet.

In dem Umfang, in dem ich normalerweise programmiere, hätte ich dann (ich habe nachgesehen...) Projekte mit zehn oder mehr Modulen, die jetzt in einem oder zwei Modulen schön übersichtlich funktionieren.

Es geht mir nicht um die Verteilung der Programme. Das ist nie ein Problem gewesen. Ob ich jetzt eine oder mehrere Python-Dateien verteile, macht keinen Unterschied, da ich sowiso immer Bilder, INI-, Datenbank- und sonstige Dateien mit verteilen muss.

Es geht mir mehr um die Übersichtlichkeit. Und viele kleine Dateien halte ich für weniger übersichtlich als wenige größere Module in denen alles drinnen ist, was zusammen gehört. Das hängt aber sicher auch davon ab, welche IDE man zum Programmieren verwendet und was jemand glaubt, dass es zusammen gehört und was nicht.

lg
Gerold

[poker]

Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.

Ich dachte, das warst du...

Hmm, OK. Im kontext zu Gerold's lätzten Post wird's mir nun klar.

Ich wüste nicht, Birkenfeld, wo ich in diesem Forum hier die "reine" Lehre verbreiten würde? Bin ja noch nicht lange hier im Forum. Wenn du diesen Topic hier meinst, dann hast du schlicht und einfach entweder meine Posts nicht richtig oder alle gelesen, oder gar verstanden.

Der reihe nach:

Sa Sep 22, 2007 00:01:
Der post der die Ansichten von OOP beschreibt, ist nicht so gemeint gewesen, das es auch meiner vollen Meinung entspricht und ich es alls meine Aufgabe betrachte das zu verbreiten. Das sollte auch aus dem sechsten Absatz und den anderen Posts hervorgegangen sein.

Nächster Punkt im Kontext zu Sa Sep 22, 2007 00:01:
Besonders diese Zitate von mir sollten dir zu denken geben:

Meine Meinung resultiert nicht daraus das andere Leute mir sagen was richtig und falsch ist, sondern durch eigene Erfahrung!

Letztendlich ist die "reine" Lehre nur soviel Wert bis man auf deren Grenzen stößt, das aber in dem Fall halt nicht gegeben ist. Deshalb empfehlen wir dir auch de anderen Lösungen weil sie "sauberer" und "pythonischer" sind.

Auch kannst du den anderen Posts entnehmen, das ich zu den anderen Pattern geraten habe weil **miner** Erfahrung nach es besser "funktioniert" als wenn man eine classe mit statics nutzt um damit ein Singelton zu emulieren (Einige der nachteiel habe ich ja genannt).

Dazu muss man nur noch beachten (auch in den Poststs ersichtlich) das ich Gerold's Intention erst viel zu spät mitgekriegt habe Im ging es um ein ganz andere Problem als ich zu erst angenommen habe. Und klar, dafür sind weder Module, Borg oder Singelton zu gebrauchen.

Gerold sucht eigentlich nach einer möglichkeit in Python die äquivalent mit Rubys ``module`` ist: http://home.vrweb.de/~juergen.katins/ru ... dules.html

Klar kann man dafür auch einfach eine Klasse nutzen, aber **und** das ist der Punkt, es ist nicht sofort ersichtlich für einen was die Intention ist. Sprich: Wenn ich (und X**N andere) sehe das einer eine Klasse als Funktionssammlung nutzt, ist **mein** erster Gedanke: "Warum keine Module!?". Sprich, die Dogmatik greift da irgendwo **doch** indirekt da man mit ``class`` was andere assoziert als der Einsatzzweck für das man es dann noch gebrauchen könnte!

In diesem Kontext (Für den Gerold und sicher viele andere auch) das haben wollen würden, wäre ein ``namespace`` Super hilfreich. Damit würde es erst gar nicht zu Ideologischen Diskussionen kommen, weil man schlicht und einfach weiß ``class`` != ``namespace`` (Auch wenn die Semantik vielleicht die gleiche bleibt!) Im übrigen würde **ich es auch** nicht schlecht finden, weil es eine zusätzliche neue Qualität der Strukturierung mitbringt die **erstmal** frei von jeder ``class`` behafteten Ideologie/Dogmatik (nenne es wie du wilst) ist .

Daher noch mal die Frage: Worum ging es dir bei deiner Ansage Birkenfeld? Für mich hinterlässt es eher den Nachgeschmack eines Bashings (Ohne dich jetzt der Trollerei bezichtigen zu wollen), den ich erkenne den Mehrwert deines postings nicht sondern eher ein implizierte leichte provokante Note!

mfg

EDIT:
Ich möchte gerne noch die ersten drei Absätze aus dem von mir verlinkten Link Zitieren:

Sobald Ihre Programme in Ruby größer und größer werden, werden Sie normalerweise bemerken, dass Sie wiederverwertbaren Code produzieren -- Bibliotheken mit ähnlichen Routinen, die allgemein anwendbar sind. Sie werden diesen Code in separaten Dateien abspeichern möchten, damit ihn auch andere Ruby-Programme verwenden können.

Dieser Code wird oft in Klassen organisiert sein, also werden Sie vermutlich eine Klasse (oder eine Reihe von Klassen, die in Beziehung zueinander stehen) in eine Datei stecken.

Manchmal kommt es jedoch vor, dass man Dinge gruppieren möchte, die normalerweise keine Klasse bilden.

Und ich denke damit steht Gerold nicht alleine da. In Ruby hat man das erkannt und deshalb gibt es dort ``module``. Da in Python Module anders definiert sind (Also lediglich dateien die selbst wider ein Objekt darstellen), würde da das von Gerold vorgeschlagenen ``namespace`` treffender sein -- Damit hätte man die gleiche Syntax und Semantik innerhalb eines Python Modules

[Leonidas]

In diesem Kontext (Für den Gerold und sicher viele andere auch) das haben wollen würden, wäre ein ``namespace`` Super hilfreich. Damit würde es erst gar nicht zu Ideologischen Diskussionen kommen, weil man schlicht und einfach weiß ``class`` != ``namespace`` (Auch wenn die Semantik vielleicht die gleiche bleibt!) Im übrigen würde **ich es auch** nicht schlecht finden, weil es eine zusätzliche neue Qualität der Strukturierung mitbringt die **erstmal** frei von jeder ``class`` behafteten Ideologie/Dogmatik (nenne es wie du wilst) ist .

Soll das etwas zusammengefasst heißen: "birkenfeld, bitte implementiere das in Python 3.0?" Wenn ich mir das so überlege - ich selbst habe selbst mal überlegt so Funktionen zusammenzufassen, aber letztendlich fand ich dass der Vorteil den es bietet zu gering ist, als dass man da weitere Syntaxkonstrukte hinzufügen müsste. Die Lösung Module dynamisch zu erstellen macht das Programm zur Laufzeit übersichtlicher, allerdings den Quellcode komplexer. Außerdem heißt es doch "Flat is better than nested.".. andererseits aber auch "Namespaces are one honking great idea -- let's do more of those!". Der Zen hat also auch zwei Meinungen dazu.

Und ich denke damit steht Gerold nicht alleine da. In Ruby hat man das erkannt und deshalb gibt es dort ``module``. Da in Python Module anders definiert sind (Also lediglich dateien die selbst wider ein Objekt darstellen), würde da das von Gerold vorgeschlagenen ``namespace`` treffender sein -- Damit hätte man die gleiche Syntax und Semantik innerhalb eines Python Modules

Ich habe ja vorgeschlagen das in Python zu implementieren. Dann kann man damit auch testen, ob das überhaupt praktikabel ist und als Beispielimplementierung würde dass auch für einen etwaigen PEP handlich sein.

[poker]

Wenn ich mir das so überlege - ich selbst habe selbst mal überlegt so Funktionen zusammenzufassen, aber letztendlich fand ich dass der Vorteil den es bietet zu gering ist, als dass man da weitere Syntaxkonstrukte hinzufügen müsste.

Naja, das ganze über ``codecs`` zu realisieren halte ich dann auch wider für zu übertrieben. Besser direkt im Python core integrieren um keinerlei Overhead in kauf zunehmen. Aber als POC IMO gut geeignet um die Praktikabilität auszutesten.

Außerdem heißt es doch "Flat is better than nested.".. andererseits aber auch "Namespaces are one honking great idea -- let's do more of those!". Der Zen hat also auch zwei Meinungen dazu.

Stimmt, ganz so konsistent ist der Zen dann noch wider nicht

Ich habe ja vorgeschlagen das in Python zu implementieren. Dann kann man damit auch testen, ob das überhaupt praktikabel ist und als Beispielimplementierung würde dass auch für einen etwaigen PEP handlich sein.

Das wäre vielleicht garnicht so schlecht ein PEP mit nem POC zu eröffnen Den POC könnte man dann, wie von dir in einem der post hier im thread vorgeschlagen, mit ``codecs`` implementieren. Dann könnte man ein wenig rumspielen; aber eigentlich: In Ruby ist es ganz praktikabel und nützlich. Ich denke in Pyhton würde es daher auch funktionieren. Müsste man mal die pythonista abstimmen lassen ob die sowas gut finden würden.

[mitsuhiko]

Ich find zwar die Idee nach wie vor bescheuert, aber mit Metaklassen kann man sich damit wenigstens virtuelle Module bauen:

Code: Alles auswählen

import sys, types

class NamespaceType(type):
  def __new__(cls, name, bases, d):
    rv = type.__new__(cls, name, bases, d)
    if namespace is not None:
        rv = rv(rv.__name__)
        sys.modules['%s.%s' % (rv.__module__, rv.__name__)] = rv
    return rv

namespace = None
class namespace(types.ModuleType):
  __metaclass__ = NamespaceType

class foo(namespace):
  def blub(self):
    print "Ich bin ein Modul"

Wenn man das jetzt in blub.py speichert kann man sowas tun:

Code: Alles auswählen

import blub
blub.foo.blub()

Oder halt auch

Code: Alles auswählen

from blub.foo import blub
blub()

//EDIT: Und Gott sei Dank haben wir nicht das Ruby Modulsystem, glaubt mir, das wollt ihr nicht

[poker]

Ich find zwar die Idee nach wie vor bescheuert, aber mit Metaklassen kann man sich damit wenigstens virtuelle Module bauen:

Code: Alles auswählen

import sys, types

class NamespaceType(type):
  def __new__(cls, name, bases, d):
    rv = type.__new__(cls, name, bases, d)
    if namespace is not None:
        rv = rv(rv.__name__)
        sys.modules['%s.%s' % (rv.__module__, rv.__name__)] = rv
    return rv

namespace = None
class namespace(types.ModuleType):
  __metaclass__ = NamespaceType

class foo(namespace):
  def blub(self):
    print "Ich bin ein Modul"

Wenn man das jetzt in blub.py speichert kann man sowas tun:

Code: Alles auswählen

import blub
blub.foo.blub()

Oder halt auch

Code: Alles auswählen

from blub.foo import blub
blub()

Sorry wenn das jetzt pampig rüberkommt aber irgendwie werde ich das Gefühl nicht los das hier einige e die Posts nicht richtig lesen!
Dan zitiere ich mich mal selber:

Klar kann man dafür auch einfach eine Klasse nutzen, aber **und** das ist der Punkt, es ist nicht sofort ersichtlich für einen was die Intention ist. Sprich: Wenn ich (und X**N andere) sehe das einer eine Klasse als Funktionssammlung nutzt, ist **mein** erster Gedanke: "Warum keine Module!?". Sprich, die Dogmatik greift da irgendwo **doch** indirekt da man mit ``class`` was andere assoziert als der Einsatzzweck für das man es dann noch gebrauchen könnte!

In diesem Kontext (Für den Gerold und sicher viele andere auch) das haben wollen würden, wäre ein ``namespace`` Super hilfreich. Damit würde es erst gar nicht zu Ideologischen Diskussionen kommen, weil man schlicht und einfach weiß ``class`` != ``namespace`` (Auch wenn die Semantik vielleicht die gleiche bleibt!) Im übrigen würde **ich es auch** nicht schlecht finden, weil es eine zusätzliche neue Qualität der Strukturierung mitbringt die **erstmal** frei von jeder ``class`` behafteten Ideologie/Dogmatik (nenne es wie du wilst) ist .

Und nichts anderes macht dein Beispiel auch. Ok, die Metaclass erzeugt das Pseudo Module und trägt es in ``sys.modules`` ein, aber an dem eigentlichen Akt der Benutzung (``class``) ändert das nichts.
Der Punkt ist durch die Einführung von ``namespace`` ...

würde es erst gar nicht zu Ideologischen Diskussionen kommen, weil man schlicht und einfach weiß ``class`` != ``namespace`` (Auch wenn die Semantik vielleicht die gleiche bleibt!)

. Punkt.

[poker]

//EDIT: Und Gott sei Dank haben wir nicht das Ruby Modulsystem, glaubt mir, das wollt ihr nicht

Nein, Rubys ``module`` (Wenn du das jetzt meinst) hat rein garnichts mit Pythons Modulen zu tun. In Ruby könne mit ``module`` eingeführte namespaces beliebig oft in einer Datei vorkommen und werden sehr oft auch zu Strukturierung genutzt. Gerold und viele aus der Ruby Welt scheinen das doch gebrauchen zu können. Ich erkenne auch kein Nachteil davon, nur vorteile.

EDIT3: In Ruby ist eine Datei mit Ruby Code kein Modu,l wie es in Python der Fall ist! Das muss man unterscheiden (Falls du das jetzt meintest).

[gerold]

Code: Alles auswählen

import blub
blub.foo.blub()

[...]
Oder halt auch

Code: Alles auswählen

from blub.foo import blub
blub()

Hallo blackbird!

Ich glaube, das hast du falsch verstanden. Es geht nicht darum, auf biegen und brechen ein "Modul" zu erzeugen, sondern um die optische Gruppierung von zusammen gehörenden Codeteilen.

Es geht um die Optik und darum, dass es manchen nicht passt, wenn man Funktionen, die zusammen gehören, einfach in Klassen rein packt.

Mein Vorschlag wäre also:

Code: Alles auswählen

namespace Foo:
    def bar():
        return "bar"
    def spam():
        return "spam"

print Foo.bar()
print Foo.spam()

Anstelle von:

Code: Alles auswählen

class Foo:
    def bar(self):
        return "bar"
    def spam(self):
        return "spam"

foo = Foo()
print foo.bar()
print foo.spam()

Das was im Beispiel der "namespace Foo" ist, würde man normalerweise in ein Modul auslagern, damit man wie im Beispiel darauf zugreifen kann. Aber oft möchte man so etwas nur für ein paar Zeilen Code verwenden. Wenn ich diese Codezeilen jedes Mal in ein eigenes Modul auslagere, dann würde der Quellcode unübersichtlich werden....
Auslagern macht natürlich Sinn, wenn der Code auch von anderen Modulen importiert werden würde. Aber das ist bei vielen kleinen Programmen von vorneherein komplett ausgeschlossen. Oft kommen so sogar zirkuläre Referenzen ins Spiel, die das Programm anfälliger machen. -- Mehrfache Importe, die eigentlich gar nicht nötig wären, da ein Modul ohne das andere Modul sowiso nicht funktioniert. Das Hauptmodul importiert das Log-Modul. Das Log-Modul importiert das Hauptmodul. -- Da stellt sich dann die Frage, warum man das übehaupt so stark voneinander getrennt hat.
Ein Namespace innerhalb eines Modules würde diese "Probleme" gar nicht erst entstehen lassen. Und wenn man später doch merkt, dass man den Namespace lieber in ein Modul ausagern würde, dann verschiebt man den Code des Namespaces in ein neues Modul und importiert im Hauptmodul das neue Modul. Fertig!

Noch mal zur Klarstellung: Es geht nicht darum, etwas logisch in ein Modul oder einen Namespace zu verschieben, sondern darum, Code der zusammen gehört auch optisch zu kennzeichnen. Und das ohne viele kleine Module erstellen zu müssen.

Das geht natürlich heute auch schon mit Klassen. Aber das stößt manch Anderen sauer hoch. -- Aus ideologischen Gründen. Und ich habe auch eine Ideologie der ich nachstrebe. Die Optik des Quellcodes muss vom Auge leicht scannbar sein. Ich will den Quellcode verstehen, noch bevor ich ihn von vorne bis hinten durchgelesen habe. Einfach durch "darüberlesen". Das erleichtert meine Arbeit und meine Art zu denken enorm.

lg
Gerold

[birkenfeld]

Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.

Ich dachte, das warst du...

Ganze Sätze Herr Birkenfeld! Also, was meinst du? Kann dir nicht folgen.

Ich zitiere dich:

Meiner Meinung sollte man Klassen nicht als Namensräume missbrauchen.

[mitsuhiko]

EDIT3: In Ruby ist eine Datei mit Ruby Code kein Modu,l wie es in Python der Fall ist! Das muss man unterscheiden (Falls du das jetzt meintest).

Nein. Ich meinte, dass du in Ruby nur einen Namespace hast und die Module einfach nur über den Constant-Lookup die Klassen suchen. Mit allen tollen Nebenwirkungen. Ist eigentlich JavaScript Module auf Drogen

[birkenfeld]

Ich habe jetzt weder Zeit noch Lust, sämtliche Posts hier durchzulesen, aber mal ein paar grundsätzliche Dinge dazu:

• PEPs ohne Implementierung stehen immer erst mal schlechter da. Eine Implementierung à la Preprocessor ist aber keine, und taugt damit auch nichts.
• Ein generisches PEP für ein "make"-Statement ist abgelehnt worden, siehe PEP 359.
• Die ganze Thematik "ich brauche aber einen Namespace!!!1" kommt mir sowieso spanisch vor. Wenn du "a.b" willst, erstell dir ein Modul "a", und fertig. Ansonsten nimm "a_b" und gut is.

[gerold]

• Die ganze Thematik "ich brauche aber einen Namespace!!!1" kommt mir sowieso spanisch vor. Wenn du "a.b" willst, erstell dir ein Modul "a", und fertig. Ansonsten nimm "a_b" und gut is.

Hallo birkenfeld!

Ich brauche keinen Namespace. Ich komme mit Klassen wunderbar klar. Aber es gibt andere Programmierer, die damit nicht klar kommen, wenn man etwas was optisch zusammen gehört, einfach in eine Klasse schreibt. Ideologie hin oder her. Wenn ich dadurch einfacher zu durchschauenden und einfacher zu lesenden Quellcode produziere, dann mache ich das einfach. Und wenn es dafür ein Namespace-Schlüsselwort gäbe, dann würde ich dieses stattdessen verwenden - nur um die Nörgler und Anhänger der reinen Lehre zufrieden zu stellen.

Und hier noch der Link in dem ich das versuche zu erklären:
http://www.python-forum.de/post-78271.html#78271

lg
Gerold

[birkenfeld]

Und ich verstehe das Grundproblem nicht. Nehmen wir mal dein Beispiel:

Code: Alles auswählen

class Foo:
    def bar(self):
        return "bar"
    def spam(self):
        return "spam"

foo = Foo()
print foo.bar()
print foo.spam()

Was für einen Vorteil hat es, dass du bar() und spam() mit dem Präfix "foo." ansprechen kannst, außer einer Gruppierung? Wenn es nämlich nur um die optische Gruppierung geht, tut es "foo_bar()" und "foo_spam()" einwandfrei.

Wenn du "foo.bar()" schöner findest, kannst du es ja gerne so lösen wie oben. Aber extra dafür ein neues Sprachkonstrukt einzuführen halte ich für fragwürdig.

[poker]

Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.

Ich dachte, das warst du...

Ganze Sätze Herr Birkenfeld! Also, was meinst du? Kann dir nicht folgen.

Ich zitiere dich:

Meiner Meinung sollte man Klassen nicht als Namensräume missbrauchen.

Tja, Birkenfeld, wenn du unfähig bist Aussagen einem Kontext zuzuordnen kann ich dir auch nicht helfen. -- Der Rest in dem Thread, bis auf einige wenige, scheinen mittlerweile zu Wissen was der Topic ist, und betrachten die ersten Aussagen von mir und BlackJack zu
diesem Kontext. Weiterhin ist erkennbar das sich ab dem Zeitpunkt der Topic verändert hat und die vorher gemachten Aussagen für **diesen** Kontext nicht mehr gelten sind! Nettes Zitat dazu: "Letztendlich ist die "reine" Lehre nur soviel Wert bis man auf deren Grenzen stößt".

Für dich verständlich Ausgedrückt:
Für Kontext eins - Ja, dafür Klassen als Namensräume zu missbrauchen, wo es auch **offensichtlich** (Und das ist offensichtlich, weil Kontext zwei nicht ersichtlich; wie auch => ``class``!!) ein Modul (Was ich vorzugsweise nutze), Borg oder Singelton tut, ist mist.

Für Kontext zwei ist man an der Grenze der "reine" Lehre gestoßen und kann dafür nicht mehr als Grundlage dienen! Um vornherein die ganzen dogmatischen Diskussionen zu vermeiden, plädieren wir auf ein ``namespace``-statement -> Ein Äquivalent zu Rubys ``module``-statement. Den ``class`` weiterhin für Kontext zwei zu nutzen, führt unweigerlich immer zur gleichen Diskussion -> Modul?! ...

Verstehst du diesen kleinen aber feinen Unterscheid? Du kannst nicht einfach eine Aussage die in einem anderen Kontext gemacht wurde - und dafür vollkommen richtig ist - herausreisen und sie auf einen anderen übertragen, für den er garnicht bestimmt war und keinerlei Geltung hat, und damit Werturteilen!

Da ich nun keine Lust habe mich weiter zu wiederholen verklinke ich einfach mal auf hier

mfg

[poker]

Nein. Ich meinte, dass du in Ruby nur einen Namespace hast und die Module einfach nur über den Constant-Lookup die Klassen suchen. Mit allen tollen Nebenwirkungen. Ist eigentlich JavaScript Module auf Drogen

Ah O.K. Hab bisher keinerlei Probleme mit gehabt aber hab schon von gehört Klar, sowas wollen wir nicht!

Ich habe jetzt weder Zeit noch Lust, sämtliche Posts hier durchzulesen, aber mal ein paar grundsätzliche Dinge dazu:

So jetzt pass mal auf Birkenfeld! Du nimmst dir das Recht heraus läuten (konkret mir) Aussagen in den Mund zu legen, in dem du Aussagen aus dem Kontext reist und sie einem andere zuordnest, und damit zu Werturteilen, **ohne** den thread gelesen zu haben? Weist du was das heißt? Zwei läute unterhalten sich, du kommst dazu hörst par Zeilen und labberst dann rum und legst läuten falsche Sachen in den Mund ohne den Zusammenhang zu kenne! Heftig oder?!
Weißt du was, wenn du es nicht für nötig erachtest es zu lesen steht dir auch kein Recht zu fremden läuten die Worte im Mund zu verdrehen und auch kein Werturteil!

Vielleicht sollte man das mal als Abwechslung mit dir machen?

Schade das ich nun sauer werden musste.

[Leonidas]

Schade das ich nun sauer werden musste.

Nur die Ruhe poker, ich denke nicht dass birkenfeld dich irgendwie wütend machen wollte. Er hat in seinem Post durchaus einige Aspekte reingebracht, die vorher noch nicht da waren.
Letztendlich ist die Gruppierung via ``prefix_`` am praktikabelsten, was ja auch mehr oder weniger deiner Idee von Gruppierung durch Kommentare entspricht.

@birkenfeld: Hast du eigentlich eine Strichliste, bei der du notierst wie oft du als Troll bezeichnet wurdest? Ich habe da dunkel einen sehr ähnlichen Thread in Erinnerung

[birkenfeld]

Für dich verständlich Ausgedrückt:

Nett von dir, danke.

Für Kontext eins - Ja, dafür Klassen als Namensräume zu missbrauchen, wo es auch **offensichtlich** (Und das ist offensichtlich, weil Kontext zwei nicht ersichtlich; wie auch => ``class``!!) ein Modul (Was ich vorzugsweise nutze), Borg oder Singelton tut, ist mist.

Für Kontext zwei ist man an der Grenze der "reine" Lehre gestoßen und kann dafür nicht mehr als Grundlage dienen! Um vornherein die ganzen dogmatischen Diskussionen zu vermeiden, plädieren wir auf ein ``namespace``-statement -> Ein Äquivalent zu Rubys ``module``-statement. Den ``class`` weiterhin für Kontext zwei zu nutzen, führt unweigerlich immer zur gleichen Diskussion -> Modul?! ...

Ist ja schön und gut, nur sehe ich keine grundsätzliche Unvereinbarkeit zwischen den "Kontexten". Der einzige Unterschied zwischen einem Singleton und einer "missbrauchten Klasse" ist doch der, dass das Singleton evtl. Daten und nicht nur Methoden hat.

Verstehst du diesen kleinen aber feinen Unterscheid? Du kannst nicht einfach eine Aussage die in einem anderen Kontext gemacht wurde - und dafür vollkommen richtig ist - herausreisen und sie auf einen anderen übertragen, für den er garnicht bestimmt war und keinerlei Geltung hat, und damit Werturteilen!

Ach Gottchen, du gehörst also auch zu diesen Leuten, die hinter jedem Satz ein vernichtendes "Werturteil" hervorlugen sehen? Oder jede Aussage bitterernst nehmen, wenn nicht drei Smileys dahinterstehen?

Ich habe jetzt weder Zeit noch Lust, sämtliche Posts hier durchzulesen, aber mal ein paar grundsätzliche Dinge dazu:

So jetzt pass mal auf Birkenfeld! Du nimmst dir das Recht heraus läuten (konkret mir) Aussagen in den Mund zu legen, in dem du Aussagen aus dem Kontext reist und sie einem andere zuordnest, und damit zu Werturteilen, **ohne** den thread gelesen zu haben?

Bis zu meinem ersten Post hatte ich das durchaus, und das hab ich auch nicht anders behauptet. Was danach folgte, hab ich nur überflogen. Der hier von dir zitierte Post enthält keinen direkten Bezug zu dir mehr.

Weist du was das heißt? Zwei läute unterhalten sich, du kommst dazu hörst par Zeilen und labberst dann rum und legst läuten falsche Sachen in den Mund ohne den Zusammenhang zu kenne! Heftig oder?!
Weißt du was, wenn du es nicht für nötig erachtest es zu lesen steht dir auch kein Recht zu fremden läuten die Worte im Mund zu verdrehen und auch kein Werturteil!

*g* Zum Thema "Werturteil" hab ich mich ja schon geäußert...

Vielleicht sollte man das mal als Abwechslung mit dir machen?

Schade das ich nun sauer werden musste.

Oh, ich werds überstehen. Mit ein paar seelischen Kratzern.

@birkenfeld: Hast du eigentlich eine Strichliste, bei der du notierst wie oft du als Troll bezeichnet wurdest? Ich habe da dunkel einen sehr ähnlichen Thread in Erinnerung

Nein, aber vielleicht lege ich mir ein an. Gleich neben meiner Duschliste...

[poker]

@Birkenfeld: Hehe, scheinst ja doch auch einstecken und nicht nur austeilen zu können Bei Gelegenheit treffen wir uns, hauen uns par in die Fresse, gehen danach in die Kneipe und trinken ein par Bier