Quote

schon klar, aber warum?

Ich denke da in erster Linie an die erweiterbarkeit. Es werden wohl noch ein paar methoden hinzu kommen. Ich persönlich denke einfach so. Bevor ich Methoden habe die:

duration_add
duration_sub
duration_set
...

besitze, dann sollte duration doch eher ein eigener Namespace sein. Wenn man ständig vor etwas einen Prefix schreibt, ist das für mich doch eher ein Indiz ein Namespace zu benutzen, und die Funktionen unter diesem Namespace zur Verfügung zu stellen.

Quote

ich weiß nicht, bei simplen integern oder strings rufst du doch in anderen sprachen auch keine methode mehr auf.

In anderen Sprachen sind meist Integer und Strings schon Objekte. Z.B. bei Ruby und Python.

Bei Ruby kannst du z.B. einfach bei allem ein ".class" anhängen und du bekommst den Objekttyp zurück. Möchtest du den Inhalt der variable klein haben hängst du einfach ein ".lc" dran. "$string.lc" und der Text ist kleingeschrieben.

Ich halte zwar von solcher einer Programmierung nicht all zu viel manchmal ist es aber auch nützlich. Und bei Perl6 wird sowas ja auch kommen. Man schaue sich "@array.elem" an um die Anzahl der Elemente zu bekommen.

Ich weiß nciht ob es kommt, aber man könnte sich sicherlich auch solche Sachen vorstellen. "@array.add('Hallo')" Um z.B. ein Element im Array hinzuzufügen. Trotzdem sollte "@array" immer noch einfach nur ein Array Repräsetieren. Die Methoden dafür sind halt Optional.

Quote

moment, moment. du hast mich glaube ich nicht verstanden. net_ftp_connect ist ja witzlos. wie gesagt, simple integer oder strings finde ich als objekte overkill. und da, wo du meinst, ein objekt haben zu müssen, mach auch eins. aber nicht implizit bei *jedem* attribut.

Ich wollte es auch gar nicht implizit bei jedem Attribut machen, und nur da wo es benötigt wird. den Code oben ist erstmal nur ein Test Code um die Technik dahinter zu verstehen und zu schauen wie man soetwas erstmal nur Implementiert.

Zum anderen werde ich nachher kein String oder so abspeichern. "$user->duration" soll mir direkt die Dauer aus der Datenbank auslesen. Und wenn ich es als Setter benutze soll der Eintrag in der Datenbank auch direkt verändert werden. Möchte ich den Eintrag in der Datenbank halt erhöhen kann ich einfach ein "add" hinten anhängen. Mir kommt das jedenfalls natürlicher vor.

Allerdings muss ich selber auch gleichzeitig dagegen sprechen. Wenn ich 4 Attribute als Klasse Implementiere, und dann 2 wiederrum als normalen Skalar kann dies ziemlich verwirrend sein, was den nun Klasse oder Skalar war.

Quote

jetzt bin ich ganz verwirrt. wenn der user eine methode add_duration hat, warum steht die plötzlich "für "name", "password", "email" zur Verfügung"?

Gute Frage!
Keine Ahnung, wo ich das geschrieben habe, war ich wohl etwas Verwirrt gewesen.

Quote

und wenn ich die duration eines users erhöhen will (was auch immer das bedeutet), dann gehört diese methode für mich schon zum user.

Ja es gehört zum User, aber eine Ebene Tiefer. Ich möchte ja nicht mit dem kompletten User Arbeiten, sondern nur mit dem speziellen Attribut.

Deswegen würde man ja auch "$user->duration_add" schreiben. Um klarzustellen das sich das "add" auf duration bezieht. Wenn man "$user->add" schreibt, würde man nicht Wissen was hier genau passiert. Daher finde ich "$user->duration->add" ziemlich natürlich.

Wenn ich vor etwas einen Prefix schreibe ist das für mich halt eher ein Indiz das ich vielleicht einen neuen namespace oder eben eine Klasse daraus machen sollte. So denke ich jedenfalls.

Quote

bis jetzt sehe ich nur, dass dir ->foo_bar nicht gefällt und du lieber ->foo->bar schreiben willst. das finde ich gut für attribute, die richtige objekte sind. wenn du der meinung bist, duration verdient eine eigene klasse, dann hält dich nichts davon ab, das zu machen.

Ich bin ja selber auch nicht damit zu frieden. Für mich sieht es auch nach Overkill aus.

Ich hätte ja gedacht das es vielleicht noch andere Tricks gibt sowas zu machen, was dann auch etwas Effizenter wäre. Ich habe mir auch überlegt ob man nicht in der Funktion angibt was man haben möchte. "Also z.B. $user->password( 'plain' )" was mir dann das Plain Passwor liefert anstatt das "Verschlüsselte". Allerdings scheint mir der Weg auch etwas komisch und nicht so Intuitiv. Bei der Möglichkeit müsste ich natürlich wieder getter und setter voneinander Trennen. Ich mag aber ehrlich gesagt beides in einem zu haben.

Quote

u.a. den vorteil, dass man auch leicht readonly-klassen erzeugen kann und man den unterschied sehr schnell sieht. naja, PBP hat mich da überzeugt =)

Soweit habe ich noch nicht gelesen. ;) Aber auch im Alpaka Buch wurde gesagt das das Trennen davon besser wäre. Habe allerdings die gründe vergessen. ;)


Wie ich das jetzt letztendlich Umsetze weiß ich noch nicht. Für mich wirkt das Teilweise auch alles zu kompliziert, was ich ehrlich gesagt auch etwas schade finde.


Kann man nicht den "->" überladen so das er zwei Argumente einer Subroutine übergibt? ;) So dass "$user->set_duration->add" letztendlich einem "user::set_duration( 'anne', 'add') entspricht? ;)

Dann könnte ich die Schreibweise beibehalten, und habe keine verschachtelte Klassen.\n\n

<!--EDIT|sid burn|1158936503-->