!= und == Depricated in 7.3.0

[VPh]

• Arrays und Objekte haben keine klare Trennung und Objekte lassen sich nicht so einfach verwenden, wie Arrays und Arrays sollten keine Keys haben (aber sollten nach wie vor Sortiert sein)

• Arrays und Objekte haben keine klare Trennung

Wat? Inwiefern?

• Objekte lassen sich nicht so einfach verwenden wie Arrays

Das verstehe ich auch nicht^^' Inwiefern sind Objekte schwieriger zu verwenden und wie sollte eine einfachere Variante aussehen?

• Arrays sollten keine Keys haben (aber sollten nach wie vor Sortiert sein)

Wie würde das die Sprache besser machen?

Beim Rest der Punkte... da macht es wohl am meisten Sinn eine Sprache einzusetzen die diese Features mitbringt. o.o
Ich wüsste gerade nicht wofür ich mir im Web-Backend Pipe-Operator, Nebenläufigkeit oder den "eigenen Ausgabekanal" wünschen sollte.

Andere Dinge, wie das "return" Keyword, sind wohl reine Geschmackssache. Mich stört das nicht, das wegzulassen würde imo eher Bugs einladen als irgendwie produktiv zu sein.

[rkr]

• Arrays und Objekte haben keine klare Trennung

Wat? Inwiefern?

Beide bringen in gewisser Weise redundante Funktionalität mit. json_encode muss raten, ob ein PHP-Array als Array oder als Objekt interpretiert werden soll.

• Objekte lassen sich nicht so einfach verwenden wie Arrays

Das verstehe ich auch nicht^^' Inwiefern sind Objekte schwieriger zu verwenden und wie sollte eine einfachere Variante aussehen?

Meinst du das jetzt ernst? Schau dir Javascript, Ruby oder Elixir an, wenn du wissen willst, wie man mit Objekten (HashMaps, Dictionaries, wording...) arbeiten kann. PHP ist hier absolut katastrophal aufgestellt mit der stdClass. Man kann beispielsweise nicht mal foreach zusammen mit stdClass verwenden. Ich brauche enorm viel Code um einfache Sachen zu machen.

• Arrays sollten keine Keys haben (aber sollten nach wie vor Sortiert sein)

Wie würde das die Sprache besser machen?

Klarere Semantik

Beim Rest der Punkte... da macht es wohl am meisten Sinn eine Sprache einzusetzen die diese Features mitbringt. o.o

Was ist denn das für ein Argument? PHP besetzt eine interessante Nische, hat aber eine völlig umständliche Syntax.

Ich wüsste gerade nicht wofür ich mir im Web-Backend Pipe-Operator, Nebenläufigkeit oder den "eigenen Ausgabekanal" wünschen sollte.

Was baust du denn für Anwendungen?

Pipe-Operator. Wenn ich die Wahl habe zwischen:

$sum = array_sum(array_map(fn, array_filter($list, fn))); 

... und:

$sum = $list |> array_filter(fn) |> array_map(fn) |> array_sum(); 

... dann nehme ich die zweite Variante.

Oder warum nicht einfach:

$sum = $list
|> filter(e => e % 2)
|> map(e => e * 2)
|> sum(e => e) 

$host = "  max.mustermann@EXAMPLE.org ;"
|> split(";")
|> first
|> lower
|> trim
|> split("@")
|> last 

Nebenläufigkeit. Wo soll ich da anfangen? Magento würde sich wahrscheinlich um Faktor 3 bis 10 beschleunigen lassen.

Eigener Ausgabekanal: Damit versehentliche Ausgaben nicht in den Browser leaken.

Andere Dinge, wie das "return" Keyword, sind wohl reine Geschmackssache. Mich stört das nicht, das wegzulassen würde imo eher Bugs einladen als irgendwie produktiv zu sein.

function pow(b, e) = b ^ e; 

vs:

function pow(b, e) {
    return b ^ e;
} 

Anderes Beispiel:

$result = switch($data) {
    "a" -> "Hello"
    "b" -> "World"
    "c" -> "Planet"
} 

[hellbringer]

$result = switch($data) {
"a" -> "Hello"
"b" -> "World"
"c" -> "Planet"
} 

$result = [
    "a" => "Hello",
    "b" => "World",
    "c" => "Planet"
][$data]; 

[rkr]

In einer switch-case Bedingung kann man einen Statement-Body hinterlegen.

[Anyone]

Der Sprache würde es ja schon mal gut tun, wenn es eine konsequente Typisierung geben würde. Momentan ist es einfach nichts Halbes und nichts Ganzes. Einhergehend mit einer konsequenten Typisierung können einige sehr schöne Sprachfeatures (z.B. Overloading oder Generics) implementiert werden. Meiner Meinung nach waren die skalaren Typehints zwar ein erster Schritt in die richtige Richtung, allerdings ein zu kleiner Schritt und scheinbar bleiben die weiterführenden Typisierungskonzepte momentan auf der Strecke, sehr schade!

Property type hints sind immer noch in der Entwurfsphase, wann kann damit gerechnet werden? PHP 10? ...

[jspit]

PHP ist hier absolut katastrophal aufgestellt mit der stdClass. Man kann beispielsweise nicht mal foreach zusammen mit stdClass verwenden.

Hier gehe ich mit foreach über die stdClass

$obj = new stdClass;
$obj->a = "value a";
$obj->b = "value b";

foreach($obj as $val){
  var_dump($val);
}
//Ausgabe: string(7) "value a" string(7) "value b" 

[rkr]

Hier gehe ich mit foreach über die stdClass

$obj = new stdClass;
$obj->a = "value a";
$obj->b = "value b";

foreach($obj as $val){
var_dump($val);
}
//Ausgabe: string(7) "value a" string(7) "value b" 

Tatsächlich. Ist aber auch wieder symptomatisch für PHP, dass man solche Sachen einfach wissen muss und nicht allein die Intuition reicht. Trotzdem ist die Nutzung von stdClass höchst selten und es steht für die meisten Operationsarten ein ganz eigenes Set von Funktionsbegriffen bereit (array_key_exists vs property_exists samt Parameterreihung).
Das machen andere Sprachen einfach viel besser und PHP unnötig kompliziert.

[JaMa]

Das hängt wohl damit zusammen, dass PHP ursprünglich nicht objektorientiert angedacht war und das erst in späteren Versionen (nach und nach) dazugekommen ist.

Ich denke aber auch dass man PHP in der Hinsicht nur komplett neu aufbauen kann. Klare Definitionen setzen und den Alt-Ballast los werden.
Hier muss ich aber auch hellbringer zustimmen, das ganze sollte dann nicht mehr PHP genannt werden. Das ist wirklich jedes mal zum Haare raufen wenn man für Angular etwas googeln muss.

Das ganze hätte dann auch den Vorteil, dass (das alte) PHP immer noch Einsteiger-freundlich und alt-bekannt bleibt und sich der Enterprise-Markt mehr Richtung "neues" "PHP" ausrichten kann.

[jspit]

Tatsächlich. Ist aber auch wieder symptomatisch für PHP, dass man solche Sachen einfach wissen muss und nicht allein die Intuition reicht.

Das solltest du dir zu Herzen nehmen bevor du mit Bemerkungen wie

Trotzdem ist die Nutzung von stdClass höchst selten und es steht für die meisten Operationsarten ein ganz eigenes Set von Funktionsbegriffen bereit (array_key_exists vs property_exists samt Parameterreihung).

versuchst die PHP-Welt zu verunsichern.

1. property_exists funktioniert selbstredend auch für das stdClass-Objekt, das somit keine Sonderbehandlung braucht wie du andeutest:

$obj = new stdClass;
$obj->a = "value a";
$obj->b = "value b";

var_dump(property_exists($obj,'a'));
$k = array_key_exists('a',$obj);  //bool(true) 

2. Das array_key_exists auch für Objekte funktioniert

class test1{
  public $a = "test1 value a";
  public $b = "test1 value b";
}

$t1 = new test1;
var_dump( array_key_exists('a',$t1));  //bool(true) 

war mir auch neu, benutzt werden sollte dies für Objekte jedoch nicht, da

Hinweis:

Aus Gründen der Abwärtskompatibilität gibt array_key_exists() auch dann TRUE zurück, wenn key eine Eigenschaft ist, die in einem Objekt, das als array übergeben wurde, definiert ist. Auf dieses Verhalten sollte man sich nicht verlassen, und es sollte darauf geachtet werden, dass array ein Array ist.

Um zu prüfen, ob eine Eigenschaft in einem Objekt existiert, verwenden Sie property_exists().

Bezüglich Parameterreihung und der Handhabung optionaler Parameter bietet PHP bei den Funktionen zugegeben ein wahres Chaos. Ist wohl in der Masse der Abwärtskompatibilität geschuldet. Aber dafür gibt es ja gute Editoren/Entwicklungsumgebungen, welche dafür Hilfe bieten.

[SirSnyder]

PR ist als Witz gemeint und bezieht sich auf dieses Thema https://externals.io/message/102251. Jedoch spannend ist, ob es nun mal Typed Properties noch in die 7.3 schaffen https://wiki.php.net/rfc/typed_properties_v2

[Anyone]

PR ist als Witz gemeint und bezieht sich auf dieses Thema https://externals.io/message/102251. Jedoch spannend ist, ob es nun mal Typed Properties noch in die 7.3 schaffen https://wiki.php.net/rfc/typed_properties_v2

Das sieht doch schon mal sehr viel versprechend aus!