static, Singleton, etc. verbieten?

[SeppJ]

Wie machst du Math.PI? Oder Math.Random()?

[volkard]

SeppJ schrieb:

Wie machst du Math.PI? Oder Math.Random()?

Das ist leicht. PI gehört wie sin und sqrt in die Klasse double und Random ist eine eigene Klasse.

[Zeus]

Scala hat object also garantierte Singletons in der Sprache eingebaut, sieht recht nett aus und macht static relativ überflüssig, sowie Enums.

[SideWinder]

volkard schrieb:

SeppJ schrieb:

Wie machst du Math.PI? Oder Math.Random()?

Das ist leicht. PI gehört wie sin und sqrt in die Klasse double und Random ist eine eigene Klasse.

Nun kannst du aber nicht an alle mathematischen Funktionen denken die für double möglich sein sollen, wie tust du nun mit weiteren "Utility"-Funktionen?

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

Ist nun aber nicht viel besser als irgendeine statische Sache. Ableiten? Nein...

Gesucht: Lokale Erweiterung eines Interfaces?!

MfG SideWinder

[Mr. N]

volkard schrieb:

SeppJ schrieb:

Wie machst du Math.PI? Oder Math.Random()?

Das ist leicht. PI gehört wie sin und sqrt in die Klasse double und Random ist eine eigene Klasse.

Also so?

class (Fractional a) => Floating a where
  pi :: a
  sqrt :: a -> a
  sin :: a -> a
  ...
instance Floating Float
instance Floating Double

class Random a where
  random :: (RandomGen g) => g -> (a, g)
  ...

[Zeus]

Oder so XD?

class MyDouble {
}

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

[Mr. N]

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.

[SideWinder]

@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

[Zeus]

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.

[Lallenbubbler]

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?

[Zeus]

Warum nicht?

var x = (3.0).sinus()

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

[Lallenbubbler]

Weil Sinus eine Funktion ist.

[Lallenbubbler]

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

[nachtfeuer]

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...;)

[SideWinder]

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

[Zeus]

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

[SideWinder]

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

[volkard]

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?

[SideWinder]

Ich glaube mir gefällt:

sqrt(d)

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

MfG SideWinder

[rüdiger]

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