3. static, Singleton, etc. verbieten?

static, Singleton, etc. verbieten?

  • M

    SideWinder schrieb:

    expansion for Number // geht dann auch alle für like Number
{
    on abs () {
        if(this >= 0) return this; 
        return -this;
    }
}

    Meinst du sowas?

    abs n = if n < 0 then -n else n

    Das geht dann für alle n in den Typklassen Num (für - ) und Ord (für < ). Man könnte auch schreiben:

    abs :: (Num a, Ord a) => a -> a
abs n = if n < 0 then -n else n

    😋 😋

    Zeus schrieb:

    Oder so XD?

    class MyDouble {
}

static class MyDoubleExention {
   static MyDouble pi(this MyDouble arg) {
   }
}

    Ich dachte genau das will Side vermeiden.

    0
  • S

    @Zeus: Wir wollen ja static vermeiden und schönes OOP machen. Also quasi die ursprüngliche Klasse erweitern um diese Methode, ohne aber abzuleiten. Einfach annehmen, dass die ursprüngliche Implementierung nicht unbedingt vollständig gewesen ist. Man muss dann eben mit dem public interface leben.

    MfG SideWinder

    0
  • Z

    SideWinder schrieb:

    @Zeus: Wir wollen ja static vermeiden und schönes OOP machen. Also quasi die ursprüngliche Klasse erweitern um diese Methode, ohne aber abzuleiten. Einfach annehmen, dass die ursprüngliche Implementierung nicht unbedingt vollständig gewesen ist. Man muss dann eben mit dem public interface leben.

    MfG SideWinder

    Tut es doch! Das static ist eher im Sinne zur Compilerzeit aufgelöst.

    Die Extension kann ja in ein ganz anderes Namespace liegen, aber soweit ich sie einbinden kann ich von mein MyDouble-Instanz einfach zahl.pi() aufrufen. Die Extension hat auch kein Zugriff auf die private Felder.

    0
  • ?

    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
Anmelden zum Antworten