RFC: Operator fuer ein striktes call_other()

[Gnomi@Uni]

Froehliches Neues Jahr, allerseits!

In unserem Bugtracker gibt es einen alten Feature-Request, ueber den wir
Ende letzten Jahres wieder vermehrt diskutiert haben: Eine Variante
von call_other(), die einen Fehler wirft, wenn die aufzurufende Funktion
nicht existiert. So eine Efun an sich sollte kein Problem sein, allerdings
sollte sie auch einen Operator wie call_other() haben. Aber wir koennen
uns fuer keinen entscheiden...

Es gibt etliche Ideen dazu:

ob=>fun() => ist zu leicht mit den Vergleichsoperatoren
>= und <= zu verwechseln.

ob.fun() . suggeriert eher Pruefung zur Compilezeit,
auch ist es optisch etwas weit von -> entfernt.

ob~>fun() Die Tilde steht eher fuer annaehernd, also
alles andere als strikt.

ob-->fun() --> fuehrt zu Doppeldeutigkeiten (if (x-->10))

ob==>fun()

ob->>fun()

ob.>fun()

ob:>fun()

ob!>fun()

ob@fun() or fun@ob()

Uns interessiert, ob Euch eine der obigen Optionen besonders gefaellt oder
ob Ihr eigene Ideen dazu habt. Alle Kommentare, die uns dabei helfen,
uns zu entscheiden, sind herzlich willkommen.

Gruss
Gnomi.

[Sin@Uni]

Aus ?call_other

ob->fun(mixed arg, ...)
ob->"fun"(mixed arg, ...)
ob->(fun)(mixed arg, ...)

da wuerde sich noch etwas wie
ob->[fun](mixed arg, ...)

anbieten.

[Ranger@Uni]

Hallo Gnomi,

ich finde aufgrund der Naehe zu anderen Programmiersprachen die Punkt-
Notation am Besten. Bei einigen Scriptsprachen passiert die Pruefung auch
erst zur Laufzeit, weswegen ich darin eigentlich kein Problem sehe.

LG, Ranger

[Sin@Uni]

Wie waers, etwas weiter zu denken, wie man das erweitern koennte
und noch den defaultwert angeben koennte:
ob->[defaultwert]fun()

defaultwert waere das Ergebnis, wenn die Funktion nicht existiert.

ob->[void]fun()
ob->[]fun()

koennte dann einen Fehler werfen, wenn die Funktion nicht existiert.

defaultwert koennte auch eine expression sein,
was das noch maechtiger machen wuerde.

[Stephan Weinberger]

Hallo,

Wie wäre es mit
-> für strict
~> für sloppy

(natürlich per compileroption/pragma zu aktivieren)

lg
Invis@BL

[Stephan Weinberger]

nach der Diskussion in ldmud-talk favorisiere ich nun "=>" für die
strikte Version.

> ob=>fun() => ist zu leicht mit den Vergleichsoperatoren > >= und <= zu verwechseln.

Das stimmt zwar, aber immerhin wirft x>=y() einen Fehler (je nachdem ob
x als object oder mixed definiert ist sogar schon zur Compilezeit).

cu
Invis@BL

[Stephan Weinberger]

Zwei Fliegen mit einer Klappe... Der Ansatz gefällt mir.

Vor allem in Verbindung mit der bereits existierenden Syntax um den
Funktionsnamen zur Laufzeit zu ermitteln
ob->[](fun)()
könnte man da wohl einige verrückte Sachen anstellen; das wäre dann
quasi gleichzeitig auch ein 'function_exists()' das Exceptions wirft :-)

Die Notation [void] würde ich allerdings eher als Defaultwert für
void-Funktionen reservieren.


Und vielleicht könnte man diese Notation dann auch gleich auch auf
andere Gebiete ausdehnen - z.B. default-Wert/Existenzcheck in mappings:

mapping foo = ([ "bar": 0 ]);
int bar = [1]foo["bar"]; // bar == 0
int baz = [2]foo["baz"]; // baz == 2
int bla = []foo["blub"]; // runtime error


lg
Invis