3. static, Singleton, etc. verbieten?

static, Singleton, etc. verbieten?

  • ?

    Wozu willst du alles an ein Objekt hängen und warum soll das schönes OOP sein? Singleton sollte man vermeiden, vorallem, wenn sie nur Ersatz für globale Variablen sind und überall Abhängigkeiten erzeugen. Aber wieso sollte man Sinus krampfhaft an ein Objekt hängen wollen? Sinus ist doch keine Methode von Zahl. Sinus ist eine Funktion. Was soll da rauskommen? 3.sinus() ändert dann den Wert von 3 und es gibt keine 3 mehr im Programm? 🤡

    0
  • Z

    Warum nicht?

    var x = (3.0).sinus()

    Es ist sinnvoll Type schmal zu halten. Aber es ist auch sinnvoll Extension anzuhängen.

    0
  • ?

    Weil Sinus eine Funktion ist.

    0
  • ?

    Man muss nicht alles von seiner natürlichen Definition wegreißen und irgendwie verobjektifizieren.

    0
  • N
    Mod

    Man kann sich bis ins tausendste hineintheoretisieren in so höhere Programierspracheneinzelheiten,...man könnte stattdessen die Zeit nutzen, um die eigende Bibliothek mit ein paar selbstgeschriebenen Assemblerroutinen zu bereichern...das schützt glaube ich auch ein wenig...;)

    0
  • S

    Lallenbubbler schrieb:

    Wozu willst du alles an ein Objekt hängen und warum soll das schönes OOP sein? Singleton sollte man vermeiden, vorallem, wenn sie nur Ersatz für globale Variablen sind und überall Abhängigkeiten erzeugen. Aber wieso sollte man Sinus krampfhaft an ein Objekt hängen wollen? Sinus ist doch keine Methode von Zahl. Sinus ist eine Funktion. Was soll da rauskommen? 3.sinus() ändert dann den Wert von 3 und es gibt keine 3 mehr im Programm? 🤡

    Weil es in der OOP nur Objekte bzw. Klassen gibt? Nicht, dass reine OOP unbedingt die schönste Form der Programmierung ist, aber das Sinus eine Funktion ist, schadet ja nicht diese an Zahl anzuhängen. Für andere Objekte ist der Sinus evtl. etwas anderes. Und klarerweise ist 3 immutable und sinus liefert den Wert zurück.

    @Zeus: Dieses Expansion-Konzept ist evtl. gut, siehe auch mein erstes Posting, vielleicht von der Syntax so:

    expansion for Number
{
    on sin () -> (Number)
    {
        // impl
        return result;
    }
}

    MfG SideWinder

    0
  • Z

    Aus Neugier, wie kommst du dazu Sprachelemente auszudenken? ^^

    0
  • S

    Zeus schrieb:

    Aus Neugier, wie kommst du dazu Sprachelemente auszudenken? ^^

    Ich lerne gerade viel im Bereich Java Enterprise, derzeit versuche ich mich im Bereich JPA/Hibernate mit dem Spring Framework und Spring MVC mit Spring Security. Dabei fällt mir auf, dass Java mich manchmal zu Dingen zwingt die mich lange zum Nachdenken bringen wie es denn nun am Besten ist nur um dann draufzukommen, dass es schlicht und ergreifend an der Sprache selbst liegt.

    Seit heute Nachmittag überlege ich ob es überhaupt besser möglich wäre 🙂

    MfG SideWinder

    0
  • V

    Lallenbubbler schrieb:

    Aber wieso sollte man Sinus krampfhaft an ein Objekt hängen wollen? Sinus ist doch keine Methode von Zahl. Sinus ist eine Funktion. Was soll da rauskommen? 3.sinus() ändert dann den Wert von 3 und es gibt keine 3 mehr im Programm? 🤡

    Also ich hätte schon Interesse daran, es in einer Richtung zu vereinfachen.

    Baum b;
cout<<b.masse()<<'\n';
double d;
cout<<d.sqrt()<<'\n';

    oder

    double d;
cout<<sqrt(d)<<'\n';
Baum b;
cout<<masse(b);

    Aber auf keinen Fall das:

    Baum b;
cout<<Botanik.masse(b)<<'\n';
double d;
cout<<Math.sqrt(d)<<'\n';//Hä? Was soll das denn?
    0
  • S

    Ich glaube mir gefällt:

    sqrt(d)

    am B/besten. Entspricht "send sqrt to d".

    MfG SideWinder

    0
  • R

    http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/abf60ad5fd03a708?pli=1
    http://comments.gmane.org/gmane.comp.web.chromium.devel/16789

    0
  • O

    Das Problem könnte man doch einfach lösen, indem man

    d.sqrt();
sqrt(d);

    parallel erlaubt. Dann könnte man auch ohne Interfaceerweiterungen einfach eine freie Funktion definieren, die sich genau so wie eine Methode verhält. Ist auch aus einer funktionalen Perspektive wesentlich schöner. Nebenbei umgeht man elegant das Problem, dass bestimmte Methoden besser in der "x.y()" schreibweise aussehen als andere, die besser mit "y(x)" aufgerufen werden.

    0
  • V

    otze schrieb:

    parallel erlaubt.

    Perl macht das so.

    0
  • S

    Welche sehen denn in der obj.method()-Syntax besser aus?

    MfG SideWinder

    0
  • ?

    @otze:

    Das verhindert dann aber wieder den eigentlich Sinn der Debatte - Nämlich die eigene Vorstellung von der idealen Objektorientierung allen anderen aufzuzwingen. Und dieses Prinzip bringt nahezu jede Diskussion in diese Richtung zwangsläufig mit sich, denn sonst hättest du einfach in jeder Sprache alles verfügbar ...

    Ich persönlich ziehe sqrt(3) eindeutig 3.sqrt vor. Denn die Wurzel ist keine der Zahl 3 eigenen Eigenschaft sondern letztlich eine algebraisch definierte und auf die konkrete Zahl angewandte Funktion. Andernfalls könnte man jeden injektiven Algorithmus als feste Eigenschaft einer jeden einzelnen Zahl auffassen.

    P.s. Ich wäre nebenbei mal dafür, die Grundrechenarten Radizieren und Potenzieren in den normalen Sprachumfang (sprich als eingebauten Operator) zur Verfügung zu stellen. In Hochsprachen scheint mir das sehr sinnvoll.

    0
  • V

    SideWinder schrieb:

    Welche sehen denn in der obj.method()-Syntax besser aus?

    Naja, im objektorientierten Spiel gibt es verdammt viele Sätze. Stets trägt das Verb die meiste Bedeutung. Aber oft ist eines der Objekte der Täter und viel wichtiger als die anderen. Es wird dann Subjekt genannt und vor das Verb geschrieben.
    Also statt

    schlagen(ich,hund,stock);

    nun

    ich.schlagen(hund,stock);

    Ich kann gut leben mit

    int i;
i.for(0,100)
  v.push_back(i);

    oder

    for(int i=0;i<100;i++)
  v.push_back(i);

    Kann ich es auch noch bei

    for(int i=0;i<100;i++)
  push_back(v,i);//Styleguide: Falls eines der Objekte das Subjekt ist, 
    //soll es an erster Stelle stehen

    Aber hört es da auf? Oder kommt knivil und macht draus

    int i;
for(i=0;<(i,100);++(i))
  push_back(v,i);

    ?

    Ob die Subjekt-Vorne-Schreibweise so prickelnd sinnvoll ist, weiß ich nicht. Man müßte es mal ausprobieren, immer eine Subjekt-Drin-Schreibweise parallel anzubieten (simpler forwarder zur eigentlichen Methode) und von außen nur den Forwarder nehmen. Ich könnte mir vorstellen, daß das gar nicht mal so unhübsch ist.

    class Boot{
   int foo(double d){
   }
   friend int foo(Boot& b,double d){return b.foo(d);}
    0
  • V

    árn[y]ék schrieb:

    Ich persönlich ziehe sqrt(3) eindeutig 3.sqrt vor. Denn die Wurzel ist keine der Zahl 3 eigenen Eigenschaft sondern letztlich eine algebraisch definierte und auf die konkrete Zahl angewandte Funktion. Andernfalls könnte man jeden injektiven Algorithmus als feste Eigenschaft einer jeden einzelnen Zahl auffassen.

    Aber Du spannst zwei Welten auf. Die programmierwelt mit b.sqrt() beo Booten und überhaupt überall, wo viel OO gemacht wird und sqrt(b) wenns mathematisch wird. Das ist von Übel und wird immer Unzufriedenheit und Reibungverluste bringen.

    0
  • Z

    Die pure OOPler machen dann:

    ich schlage: hund mit: stock
    0
  • V

    Zeus schrieb:

    Die pure OOPler machen dann:

    ich schlage: hund mit: stock

    nein, dann lieber

    ich schlage opfer=hund waffe=stock

    Lassen wir Smalltalk am besten bei Seite, was konkrete Syntax angeht, und stellen uns OO anhand anderer Sprachen vor, das führt sonst nur zu ärger mit ein paar Smalltalk-Fanboys hier. Konzepte wie Metaklassen kannste natürlich gerne zeigen, das würde ja auch der Ort für seine statics sein.

    0

  • SideWinder schrieb:

    @Zeus: Wir wollen ja static vermeiden und schönes OOP machen.

    DU willst das vielleicht 😉

    IMO ist das nicht-vorhandensein von freien Funktionen eine der schlimmsten Sachen in Java, C# oder ähnlichen Sprachen.
    Wer sagt dass freie Funktionen böse sind, und nicht OOP?

    Das führt doch bloss zu völlig fragwürdigen Hilfsklassen, die nur statische Methoden enthalten, weil freie Funktionen ja pöse sind.
    In C# hat man das ganze sogar so weit getrieben, dass man ganze Klassen explizit als solche fragwürdigen Hilfsklassen deklarieren kann, indem man sie static macht *schauder*. Wo da jetzt noch der grosse Unterschied zu nem Namespace mit freien Funktionen sein soll, entzieht sich mir völlig.
    (OK, eine Klasse kann man soweit ich weiss nicht auf zwei oder mehr Assemblies aufsplitten, nen Namespace sinnvollerweise schon, aber das war's dann glaube ich auch schon)

    Klar könnte man die statischen Methoden auch ganz verbieten, nur würde es vermutlich nicht viel ändern. Sin() etc. würden dann zu nicht-statischen Methoden einer "Math" Klasse, ala so:

    double a = 1.23;
Math m = new Math();
double s = m.Sin(a);

    Ausser dass der GC mehr zu tun bekommt, ändert sich nix.

    Natürlich könnte man auch die Primitiven Datentypen zu vollwertigen Klassen hochstufen, und ihnen Funktionen wie Sin() etc. verpassen. Bloss... wie soll man dann jemals selbst Funktionen programmieren die ebenfalls nur mit Primitiven Datentypen arbeiten?
    OK, man könnte natürlich etwas machen wie es die Extension-Methods in C# sind, also eine Möglichkeit schaffen Klassen nachträglich zu erweitern.

    Nur... wo, ausser der Schreibweise, ist da dann noch der Unterschied zu freien Funktionen?

    0
Anmelden zum Antworten