interessante frage zum string casting

[ghostgambler]

Original geschrieben von wahsaga
Ich persönlich würde es begrüßen, wenn PHP 6 (oder sonstige nachfolgende Version) einen solchen radikalen Schnitt machen würde - auch wenn dann in PHP 4/5 geschriebene Scripte nicht mehr ohne umfangereichere Anpassungen lauffähig wären. Wer nicht adaptieren will, müsste dann halt auf dem Level von PHP 5 bleiben.

Vor allem da sowieso relativ viele "Features" entfernt werden, welche das Upgraden eh zerstören... (magic_quotes ist praktisch bei jedem Hoster an, gleiches gilt für register_globals...)

Aber ich denke, zu einem Schritt mit solch weitreichenden Konsequenzen wird den PHP-Entwicklern der Mut fehlen.

Wenn wir schon beim Spekulieren sind ^^: Ich denke dass php daran krepieren wird. Nicht in naher Zukunft, aber langsam und sicher...
Es ist nun mal irgendwann ein Punkt erreicht, wo man sich, notgedrungen, von altem Ballast befreien muss, damit es vorwärts gehen kann.

Wobei es dann im Endeffekt ja egal ist, ob die "neue" Sprache als php7, oder XYZ bezeichnet wird *zucks*

Original geschrieben von jahlives
Sorry, dass ich hier auch noch meinen Senf dazu geben muss, aber was hast du denn dagegen, dass man in PHP eben === verwenden sollte, wenn man solchen Problemen aus dem Weg gehen will ?
Das TypeCasting finde ich ehrlich gesagt eine nette Sache. Klar gemäss einer richtigen Programmiersprache nicht korrekt, aber für eine Sprache wie PHP doch genau richtig.

closure sieht es in sofern als schlecht an, dass selbst eine so eindeutige Abfrage wie

if ((string)'0x2BAD' == (string)'11181') 

wo deutlich sein sollte, dass man einen STRING-Vergleich haben will, beides in Integer konvertiert und dann erst verglichen werden.
Und da hat closure, bei aller liebe zu dem dynamischen Casting, recht, das da oben sollte als String verglichen werden, spätestens durch das explizite Typecasting

[Lennie]

darf ich nun davon ausgehen, dass die beiden werte die selbe zahl beinhalten, lediglich sich zwischen he und intval utnerscheiden?
somit ist es der (string)'xxx' egal, welche formatierung die zahl hat?

[closure]

Original geschrieben von ghostgambler
Das lehrt dich jedoch nur den kommerziellen Teil. Ich "arbeite" zwar nur gemeinnützig, aber mindestens eine Website übersteigt von der Request-Anzahl mit Sicherheit, viele viele kommerzielle Websiten (2.5 Mio PIs am Tag, davon träumen einige Websitenbesitzer ^^,)

Das sagt nur leider wenig über die fähigkeiten aus.
Ein script dass einfach nur "hallo welt" wird den server nicht sonderlich
belasten wenn die request-frequenz hoch ist.
Nimm das bitte nicht zu wörtlich mir ist schon klar dass es sich nicht
einfach nur um ein hallo-welt-scriptchen handelt.

Original geschrieben von ghostgambler
Du vergisst aber auch, dass PHP erst langsam in Richtung OOP schwenkt. PHP4 war in Sachen OOP praktisch unnutzbar, erst mit PHP5 kamen Features, die die OOP sinnvoll machten; ich erwarte eigentlich, dass da im Laufe der Zeit..

Ja sicher, das ist ja auch gut. Aber die entwickler tun es nicht konsequent
genug. Das wollen sie laut eigenen aussagen auch gar nicht. Sie wollen
ja gar nicht das php zu sehr objektorientiert wird.

Original geschrieben von ghostgambler
Meinst du bei irb nur das einfache Eingeben von Kommandos?
e.g. wie hier benutzt um ruby zu lehren http://www.ruby-lang.org/en/documentation/quickstart/
Vielleicht habe ich das Konzept der interaktiven Shells (Ruby, Python) einfach nicht geblickt, aber abgesehen von einer Spielerei zum Testen der Sprache, konnte ich diese Shells bisher nicht zum Programmieren produktiver Endprodukte nutzen.

Es ist schon etwas mehr. Das ding ist eine art REPL. Du kannst
am laufenden system dinge verändern, reimplementiert und ausprobieren.
Und wenn du damit zufrieden bist was du gemacht hast übernimmst du
es in deine codebase. Auch eine agile technik.

*schild schwenk* folgendes Argument ist billig, ich wollte es nur mal gesagt haben

Was ist daran billig wenn ich fordere dass mich eine arbeit möglichst nicht
frustriert. Wenn sie es nicht tut bin ich motivierte und produktiver.
Geht dir das nicht so ?

Wer sich aber auch auf die dynamische Konvertierung einer kompletten Klasse in einen booleanen Typ verlässt, hat es nicht anders verdient :P

ack. Aber manchmal weiss man gar nicht so recht dass man da gerade
ein objekt auf FALSE prüft.
Stell dir vor die folgende generische fabrik erstellt instanzen von
beliebigen klassen. Du weisst noch nicht welche konkreten klassen
später einmal gebaut werden sollen.
Zum testen gibst du zunächst mal bei erfolg das objekt und bei misserfolg
FALSE zurück.

if(FALSE == ($obj = create_some_object('myclass'))){
   echo 'oh oh';
}else{
  //do sth
} 

myclass hat per definition keine member. Obwohl die erzeugung
funktioniert hat, handelst du aufgrund des verhaltens des vergleichsoperators
als hätte sie das nicht.
Diese art fehler braucht man nun wirklich nicht.

Das MPO/CLOS sieht in der Theorie recht fein aus (wie praktisch alles in der Theorie immer so gut aussieht ^^), jedoch fürchte ich auch da um eine fehlenden Integrität der geschriebenen Klassen ... aber das ist nur Spekulation, ich werde mir das vor weiteren Äußerungen demnächst erstmal in der Praxis anschauen.

Das lass ich mal so stehen bis du es dir angeschaut hast.

Sry, hatte den Artikel gestern in den 5 Minuten Pausen zwischen einer Serie gelesen und dabei wohl das wichtigste überlesen ^^;
Du hast natürlich recht, php bietet das nicht wirklich... Allerdings muss ich dazu sagen, dass ich das bisher auch noch nicht vermisst habe

Kommt sicher noch.

Das ist eine se~hr abstrakte Antwort auf meine Frage.
Exceptions sind und sollten in jeder besseren objektorientierten Sprache vorhanden sein (ich hoffe doch in Ruby auch? Ansonsten hat PHP da doch tatsächlich sprachlich mal die Nase vorn ^^)
Und die Diskussion um abstrakte Kontrollstrukturen, als Ersatz für bereits vorhandene, ist an dieser Stelle spätestens nach den schon Jahre andauernden Diskussionen um GOTO, hinfällig; deshalb gehe ich da nicht weiter drauf ein

Im beispielcode zu generatoren ist ein ganz praktischer anwendungsfall
gegeben. Probier das mal ohne continuations.
Mit GOTO hat das nichts zu tun.
Natürlich kennt ruby exceptions. Sonst würde ich nicht so lange texte verfassen.

Da ist die Ableitung von SPL in PHP wesentlich hübscher gemacht, die Continuations sind an der Stelle richtig scheußlich...

Du findest es also angebracht wenn subclassing gewählt wird obwohl
aggregation oder containment gemeint ist ?

Namensgebung mit Unterstrichen ... ich weiß, dass es billig ist, aber es funktioniert. Und Namespaces sind im Endeffekt auch nichts anderes + Automatismus *zucks*

Naja es ist schon was anderes. Wenn der interpreter das richtig handled
kann man sogar zur laufzeit speicher sparen. Ist aber für
php nicht so interessant. Mir geht es vor allem um die vermeidung
von namenskonflikten. Namespaces sind nun wirklich kein schweres thema.

Ja, aber ich verstehe nicht was daran so toll sein soll und/oder wieso es ein Vorteil von Ruby gegenüber PHP sein kann/ist?

Es ist doch toll wenn ein objekt wenn es auf bestimmte methoden antwortet,
dann ganz sicher so behandelt werden kann wie alle anderen objekte die
auf eben diese methode antworten.

@wahsaga
Ihnen fehlt nicht nur der mut sondern auch der wille und ich befürchte
auch irgendwie das knowhow.
Bei der sache mit dem willen spielen auch finanzielle interessen eine rolle.

[Lennie]

OffTopic:

---

und ein offtopic eintrag
Ich glaube nicht, dass PHP verloren geht. Momentan ist es für Serverseitiges programmieren ohne große konkurenz.
Was ich allerdings glaube, dass PHP bald einen Punkt erreicht, andem es aufgegeben wird, weiter zu entwickeln, da es einfach immer verwurzelter wird.

---

[closure]

Original geschrieben von jahlives
Sorry, dass ich hier auch noch meinen Senf dazu geben muss, aber was hast du denn dagegen, dass man in PHP eben === verwenden sollte, wenn man solchen Problemen aus dem Weg gehen will ?
Das TypeCasting finde ich ehrlich gesagt eine nette Sache. Klar gemäss einer richtigen Programmiersprache nicht korrekt, aber für eine Sprache wie PHP doch genau richtig.

Ich hab nix gegen dynamische typisierung. Aber willkürliche und nicht
nachvollziehbare casts unter der haube finde ich nicht schön.

Zum Thema Java: Also nur weil es 8 primitive Datentypen gibt, die nicht Objekte sind, würde ich Java trotzdem noch als Objekt Sprache bezeichnen.

Ich bezeichen java auch als objektorientiert, aber nicht als pure objectoriented.
Kleiner unterschied.
Zum thema eigner booltyp. Stell dir ein kalkül vor in dem alles genau umgekehrt
ist. Wahre aussagen sind falsch und falsche aussagen sind wahr.
Da bekommt man doch einen knoten im kopf wenn man sich nicht einen typen
baut der es genau so macht.

greets

[ghostgambler]

Original geschrieben von closure
Was ist daran billig wenn ich fordere dass mich eine arbeit möglichst nicht
frustriert. Wenn sie es nicht tut bin ich motivierte und produktiver.
Geht dir das nicht so ?

ich meinte mein Argument

Zum testen gibst du zunächst mal bei erfolg das objekt und bei misserfolg
FALSE zurück.

if(FALSE == ($obj = create_some_object('myclass'))){
   echo 'oh oh';
}else{
  //do sth
} 

Bei Misserfolg wäre auch null akzeptabel und das wiederum würde sich abfangen lassen

Im beispielcode zu generatoren ist ein ganz praktischer anwendungsfall
gegeben. Probier das mal ohne continuations.

Wenn es wirklich nur mit Continuations gehen sollte, ist das echt schwach... (aber du redetest ja auch von Ruby-internen Iteratoren?!)
Den Code versteht man doch spontan praktisch gar nicht; so mehr oder minder verständlich noch die normale Syntax von Ruby ist, dass da, versteht man auf keinem Fall mit einem Blick...

Mit GOTO hat das nichts zu tun.

Guck mal bei Google, sehr häufig findet man den Vergleich mit GOTO und der ist im Endeffekt auch nicht sonderlich abwegig, auch wenn die Continuations mehr Macht und Freiraum bringen (man damit dann aber auch viel leichter überhaupt nicht mehr nachvollziehbaren Code produzieren kann...)

Du findest es also angebracht wenn subclassing gewählt wird obwohl aggregation oder containment gemeint ist ?

Ja. Wie gedenkst du die Aggregation in diesem Falle anders umzusetzen?
In deinem Beispiel vorhin in Ruby mit Continuations, hast "du" (auch wenn es nicht von dir stammte) auch auf Vererbung gesetzt um die Aggregation umzusetzen. Es ist einfach am zweckmäßigsten...

[closure]

Original geschrieben von ghostgambler
Bei Misserfolg wäre auch null akzeptabel und das wiederum würde sich abfangen lassen

jipp. Frage der intuitivität.

Wenn es wirklich nur mit Continuations gehen sollte, ist das echt schwach... (aber du redetest ja auch von Ruby-internen Iteratoren?!)
Den Code versteht man doch spontan praktisch gar nicht; so mehr oder minder verständlich noch die normale Syntax von Ruby ist, dass da, versteht man auf keinem Fall mit einem Blick...

Nicht ruby-intern sondern interne iterator. Es ist so das python wie auch
c++ und java nur externe iteratoren kennt weswegen sie als ersatz für
interne iteratoren generatoren benutzen müssen.
Continuations sind sicher nicht das einfachste thema. Ich muss zugeben
dass ich daran auch zuknabbern hatte/teilweise habe. Aber sie sind
mächtig.

[..] auch wenn die Continuations mehr Macht und Freiraum bringen (man damit dann aber auch viel leichter überhaupt nicht mehr nachvollziehbaren Code produzieren kann...)

Jipp. Man muss das schon sehr gezielt einsetzen.

Ja. Wie gedenkst du die Aggregation in diesem Falle anders umzusetzen?
In deinem Beispiel vorhin in Ruby mit Continuations, hast "du" (auch wenn es nicht von dir stammte) auch auf Vererbung gesetzt um die Aggregation umzusetzen. Es ist einfach am zweckmäßigsten...

Vererbung beschreibt eine "is-a"-beziehung. Gemeint ist aber eigentlich
eine "has-a" beziehung. Die wird einfach durch member modelliert.
Beispiel: Ein auto hat einen motor -> aggregation
Aber: Ein moter ist kein auto.

Also:

class Car{
    private:
         Engine engine_;
};

und nicht

class Engine : public Car{
};

Die spl bindet z.B. auch iteratoren zu sehr an die container.
Das Fileobjekt erbt von RecursiveIterator und SeekableIterator.
Dadurch wird structure und algorithmus in eine "is-a" beziehung gesetzt.
Richtig wären hier externe iteratoren und structuren mit generischen interfaces
zu diesen iteratoren.

Als c++ beispiel zum iterieren über einen std::vector<std::string>

for(std::vector<std::string>::const_iterator it = some_vec.begin(); it != some_vec.end(); ++it){
     //do sth with *it
}

So macht es auch sinn, weil man auf diese weise generisch auf jeder
art von container arbeiten kann immer mit dem selben interface.
Das kombiniert mit funktionsobjekten und schon hast du einen großen
teil aus algorithm.h

[ghostgambler]

Original geschrieben von closure
Vererbung beschreibt eine "is-a"-beziehung. Gemeint ist aber eigentlich
eine "has-a" beziehung. Die wird einfach durch member modelliert.
Beispiel: Ein auto hat einen motor -> aggregation
Aber: Ein moter ist kein auto.

Die Frage ist, ist es wirklich eine has-a-Beziehung?
Ein Directory-Objekt kann ja auch als ein Iterator selbst angesehen werden, damit wäre es dann eine is-a-Beziehung (und das lässt sich auf andere Anwendungsfälle übertragen) ... aber das ist wahrscheinlich auch eines der Themen, wo man von philosophischer Seite her, eine Menge drüber labern kann...


Wenn es recht ist, will ich deine Meinung da lieber noch zu was anderem hören ^^
Während php relativ einfach zu lernen ist, beschränkt sich der Nutzen doch nur aufs Web; während Ruby da doch gestreuter agiert...
Jetzt hab ich hier nen kleinen Jungen, der will programmieren lernen und ist sich wohl nicht sonderlich sicher, ob er jetzt Websiten oder Spiele programmieren will ... würdest du ihm Ruby als Programmiersprache, auch für "Spiele" empfehlen (es sollte schon etwas mehr möglich sein, als ein reines Konsolenspiel, ein High-End-3D-Spiel muss er damit aber jetzt auch nicht programmieren können...)

[3DMax]

Original geschrieben von closure Schau dir mal
an was in php alles als FALSE gilt.

      das boolean FALSE selbst

      die Integer 0 (Null)

      die Fließkomma-Zahl 0.0 (Null)

      die leere Zeichenkette und die Zeichenkette "0"

      ein Array ohne Elemente

      ein Objekt ohne Mitgliedsvariablen

      der spezielle Typ NULL (einschließlich nicht definierter Variablen)

Da sind 5 überraschungen. Alles ab Fließkomma 0.0.
Was soll das ? Warum ist ein array() ohne element FALSE ?
Warum ist ein objekt ohne member FALSE ?
Warum gilt FALSE == "" == "0" ?

ist das nicht bei allen ungetypten scriptsprachen so?
php bietet aber dazu auch explizit funktionen an:

is_null()
is_bool() 
is_numeric() 
is_float() 
is_int() 
is_string() 
is_object() 
is_array()

und ja, ich gebe zu, dass das verhalten manchmal "merkwürdig" ist, aber man kann sich darauf einstellen, z.b. '===' und/oder o.g. benutzen

ich verstehe nur nicht, warum du uns permanent mit deinem "ruby-ist-geil-gedöns und ich habe den allerlängsten" langweilst?

wenn dir php nicht passt, dann lass es doch und such dir ein forum wo du unter deinesgleichen bist.
und dass du dich mit der programmiersprache "brainfuck" beschäftigst, spricht für sich und gegen dich!

.. und was garnicht geht, ist jetzt, dass alle programmiersprachen in einen topf geworfen werden (java, js, c, c++, etc.) völlig sinnlose diskussion - alle sprachen haben ihre vorteile (ansonsten hätten sie keine daseinsberechtigung bzw. wären sie nicht existent).
nachteile habe sie alle, objektiv und/oder subjektiv.

[wahsaga]

Original geschrieben von 3DMax
ich verstehe nur nicht, warum du uns permanent mit deinem "ruby-ist-geil-gedöns und ich habe den allerlängsten" langweilst?

Wenn's dich langweilt, verstehe ich nicht, warum du dich überhaupt zu einer Einmischung herablässt :-)

Sieh's doch eher als Möglichkeit, mal über den Tellerrand hinauszublicken ...

PHP's größte "Stärke" ist sicherlich seine Verbreitung - in der dürfte es den meisten serverseitigen Techniken weit überlegen sein.
Deshalb, und auch weil ich vielleicht gerne in PHP scripte und die Sprache trotz ihrer Schwächen mag, muss ich doch aber nicht gleich aufheulen, wenn jemand auch mal eine andere interessante Technik näher beleuchtet - und mich auch nicht an meiner Ehre gepackt fühlen, wenn jemand den Finger in die Wunde legt, was die konzeptionellen Schwächen von PHP angeht.

[onemorenerd]

Wuhiaa, das is der lesenswerteste Thread seit langem!
Leider eignet sich ein Forum nicht so recht für solche Diskussionen. Euch scheints ja kaum zu stören, ihr bleibt hartnäckig dabei. Aber irgendwie dreht ihr euch im Kreis, bringt immer wieder die selben Argument, was nur wegen der professionellen Wortwahl und des eingestreuten Codes nicht gleich auffällt. Versteht es bitte nicht falsch, ich habs gern gelesen und Respekt vor euch beiden, dreien oder wieviele jetzt eben dabei waren. Hätte ich die Zeit, würde ich mich gern an der Diskussion beteiligen.
Noch lieber würde ich Ruby lernen, denn closure als Verfechter dieser Sprache verdient wie ich seine Brötchen mit Softwareentwicklung, er machts aber mit Ruby und scheint damit so schnell fertig zu sein, dass er ziemlich viel Freizeit hat.

(Ja richtig, das war ein Scherz. Muß man nicht kommentieren. Schön beim Thema bleiben. Seid eisern!)

Ich bin vorhin kurz hochgeschreckt als ich las, dass jemand PHP den Untergang prophezeit. Hush!
Habe mich irgendwie an diese Sprache mit all ihren Macken und Unzulänglichkeiten "gewöhnt". PHP hat Profil. Man kann es kennen lernen und dann noch jahrelang immer besser verstehen. Wie die süße Blonde damals im Park, die ich heute noch ... aber bleiben wir bei PHP: Diese Sprache ist gewachsen und entwickelt sich immer noch weiter. Sie wurde nicht am Reissbrett entworfen sondern nahezu ohne softwaretheoretisches Konzept in die Welt geboren. Seitdem findet sie immer mehr Anhänger, in erster Linie weil die Einstiegshürde so niedrig ist. Die Anwendercommunity beeinflußt die Weiterentwicklung, deren Richtung, Geschwindigkeit und Rückwärtskompatibilität. Bei PHP sicher mehr als bei Ruby. Und PHP-Anwender sind eben keine studierten Profis auf der Suche nach der perfekten Enterprise-Sprache sondern mal überspitzt gesagt Leute, die ihre Homepage mit ein wenig Dynamik aufpeppen wollen.
Solche - nennen wie sie mal Einsteiger - wirds immer geben. Daher glaube ich nicht, dass mein liebgewonnenes PHP untergehen wird.
Ich denke es wird sich noch ein wenig weiter entwickeln und dabei in der Syntax konsistenter werden. Closures, Idiome und selbst Reflection sind dem typischen PHP-Nutzer aber fremd, für dynamische Webseiten auch nicht zwingend notwendig. Aus diesem Grund und der Historie von PHP wirds eben nie eine Profisprache werden. Sie bleibt die Sprache ihrer Nutzer.
Das schmeckt marktwirtschaftlich, Nachfrage bestimmt Angebot, und ist den Informatikern unter uns natürlich ein Stich ins Herz. Aber hey, es darf jeder sein Heil suchen wo er möchte! Ich empfehle den Park.


Dieser Beitrag enthält demonstrativ kein Zitat.

[3DMax]

Original geschrieben von wahsaga
Wenn's dich langweilt, verstehe ich nicht, warum du dich überhaupt zu einer Einmischung herablässt :-)

trotz deines smilies - das ist immer noch "mein" thread!

Original geschrieben von wahsaga
Sieh's doch eher als Möglichkeit, mal über den Tellerrand hinauszublicken ...

das ist aber nun mal ein thread in einem fachspezifischem thema - oder?

ich stelle mir gerade ein posting in einem deutsch-forum vor:
titel: "welcher artikel ist der richtige?"
op: heißt es "der", "die" oder "das" substantiv?
closure: "deutsch ist scheiße, benutze english, da brauchst du nur 'the'"

so viel zum thema "tellerrand". es ist in 'PHP Developer Forum' einfach ot! aber verschiebt es meinetwegen nach ot, kommt ja eh nichts sinnvolles außer closure's lobpredigen dabei heraus.

[closure]

Original geschrieben von 3DMax
ist das nicht bei allen ungetypten scriptsprachen so?
php bietet aber dazu auch explizit funktionen an:

Nö.
Und auch nicht bei allen dynamisch typisierten sprachen.

ich verstehe nur nicht, warum du uns permanent mit deinem "ruby-ist-geil-gedöns und ich habe den allerlängsten" langweilst?

Nicht nur ruby ist geil. Es gibt auch noch andere sprachen die toll sind.
Vll kennst du ja die ein oder andere die für dich an php "heranreicht".
Achso und ich wette deiner ist länger.
Also ich meine deinen arbeitstag und deinen code wenn wir die implementierung
der lösungen zum selben problem in beiden sprachen vergleichen würden.

wenn dir php nicht passt, dann lass es doch und such dir ein forum wo du unter deinesgleichen bist.
und dass du dich mit der programmiersprache "brainfuck" beschäftigst, spricht für sich und gegen dich!

Ich habe nie gesagt dass mir php nicht passt. Mir passen einige "features" nicht.
Seht es doch als fingerzeig für verbesserungen. Es muss doch nicht
immer gleich ein heiliger krieg angezettelt werden. Bis jetzt jedenfalls
empfand ich den thread als sehr sachlich.
Es spricht gegen dich dass du, und das impliziert dein statement, dich nicht
mit brainfuck beschäftigst. Dir sind wahrscheinlich auch endliche automaten
fremd.

.. und was garnicht geht, ist jetzt, dass alle programmiersprachen in einen topf geworfen werden (java, js, c, c++, etc.) völlig sinnlose diskussion - alle sprachen haben ihre vorteile (ansonsten hätten sie keine daseinsberechtigung bzw. wären sie nicht existent).
nachteile habe sie alle, objektiv und/oder subjektiv.

Das hat nie jemand in abrede gestellt und wenn du aufmerksam gelesen
hättest wüsstest du das dauch.

onemorenerd
cosure als Verfechter dieser Sprache verdient wie ich seine Brötchen mit Softwareentwicklung, er machts aber mit Ruby und scheint damit so schnell fertig zu sein, dass er ziemlich viel Freizeit hat.

Ich kommentier das trotzdem mal. Keep it simple. The art of maximizing
the amount of work not done. Dann klappts auch mit der freizeit.
Aber mal ganz ehrlich, in der tat habe ich wirklich mehr freizeit durch
neue arbeitsmethoden und ruby als sprache.
Ansonsten gehe ich mit deiner antwort konform.

Original geschrieben von ghostgambler
Die Frage ist, ist es wirklich eine has-a-Beziehung?
Ein Directory-Objekt kann ja auch als ein Iterator selbst angesehen werden, damit wäre es dann eine is-a-Beziehung

Es ist eindeutig eine is-a beziehung.
Nee ein verzeichnis ist kein iterator. Ein iterator ist ein abstraktes gebilde
das es ermöglicht über die menger der vom verzeichnis enthaltenen
element zu iterieren.

Original geschrieben von ghostgambler
Jetzt hab ich hier nen kleinen Jungen, der will programmieren lernen und ist sich wohl nicht sonderlich sicher, ob er jetzt Websiten oder Spiele programmieren will ... würdest du ihm Ruby als Programmiersprache, auch für "Spiele" empfehlen (es sollte schon etwas mehr möglich sein, als ein reines Konsolenspiel, ein High-End-3D-Spiel muss er damit aber jetzt auch nicht programmieren können...)

Er sollte lisp lernen. Jeder sollte lisp lernen
Im ernst. Ruby ist nicht geeignet für spieleentwicklung. Dafür ist es im
moment zu lahm und braucht zu viel speicher. Wenn es um spiele geht
ist c++ die sprache der wahl. Allerdings wird ein programmieranfänger
so schnell kein spiel zu stande bringen.
Für webgeschichten und generell zum programmieren lernen,
naja da würde ich natürlich zu ruby raten.


greets

[Slava]

zur Thema:
interessante frage zum string casting

wir müssen einfach akzeptieren, dass operator== in PHP nicht der operator==, der in anderen Sprachen vorhanden ist, und hat ganz andere Funktionalität.
Ich wiederhole noch mal, dass "==" ist dafür ausgedacht worden um die gleicheit zwischen Variablen zu finden, die sogar zu Anderen Typen gehören.
Wenn Sie ein Vergleichoperator von anderen sprachen meinen, der heisst in PHP operator===.
Ich sehe in dem Verhalten von "==" in unserem erstem Beispiel keine Anomalie, und als Bug, kann man das sowieso nicht bezeichnen.
operator== hat in php immer auf die Typen von Variablen gepfiffen und ist auch extra dafür gemacht worden, um uns Typenumwandlung bei Vergleich von Variablen zu sparen.

Zur Ruby:
da ich Arbeitslos bin, würde ich mich bei einem Arbeitsangebot als Ruby-Programmierer sofort in Ruby verlieben.
bis dahin, werde ich versuchen einwenig Ruby zu verstehen, obwohl sein Syntax mir völlig fremd vorkommt.

[ghostgambler]

Original geschrieben von Slava
Ich sehe in dem Verhalten von "==" in unserem erstem Beispiel keine Anomalie, und als Bug, kann man das sowieso nicht bezeichnen.

closure sieht es in sofern als schlecht an, dass selbst eine so eindeutige Abfrage wie

if ((string)'0x2BAD' == (string)'11181') 

wo deutlich sein sollte, dass man einen STRING-Vergleich haben will, beides in Integer konvertiert und dann erst verglichen werden.
Und da hat closure, bei aller liebe zu dem dynamischen Casting, recht, das da oben sollte als String verglichen werden, spätestens durch das explizite Typecasting

Du siehst es also nicht als Bug an, wenn ich als Programmierer beide Typen explizit nach String konvertiere und die Programmiersprache dann beide Werte wieder nach int umwandelt um den Vergleich zu machen?