Funktioniert:
define('x', 1+1);
define('y', 'a'.'b');

Funktioniert nicht:

class foo {
const x = 1+1;
const y = 'a'.'b';
}

Können Operatoren bei der Definition von Klassenkonstanten prinzipiell
nicht verwendet werden, oder überseh ich was?

Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Gregor Kofler schrieb:

> Funktioniert:
> define('x', 1+1);
> define('y', 'a'.'b');
>
> Funktioniert nicht:
>
> class foo {
> const x = 1+1;
> const y = 'a'.'b';
> }

Definiere "Funktioniert nicht". Fehlermeldung? Falsche Ergebnisse?

Gruß. Claus

Gregor Kofler schrieb:
> Funktioniert:
> define('x', 1+1);
> define('y', 'a'.'b');
>
> Funktioniert nicht:
>
> class foo {
> const x = 1+1;
> const y = 'a'.'b';
> }
>
> Können Operatoren bei der Definition von Klassenkonstanten prinzipiell
> nicht verwendet werden, oder überseh ich was?

Das gilt, wenn ich es recht überblicke, für alles, also auch für
Members. Es geht:

private $foo = NULL;
private $foo = array();
private $foo = "foo";


Aber nicht:

private $foo = 1+1;
private $foo = str_replace("fuu", "foo", "This is fuubar");
private $foo = new Foo();

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html

Claus Reibenstein meinte:
> Gregor Kofler schrieb:
>
>> Funktioniert:
>> define('x', 1+1);
>> define('y', 'a'.'b');
>>
>> Funktioniert nicht:
>>
>> class foo {
>> const x = 1+1;
>> const y = 'a'.'b';
>> }
>
> Definiere "Funktioniert nicht". Fehlermeldung? Falsche Ergebnisse?

Mit "funktioniert nicht" meinte ich, dass diese Konstruktion nicht
"funktioniert" - deshalb auch meine dahingehende Frage.

Der Vollständigkeit halber:

Die IDE schreit schon "expecting , or ;" und hebt den Operator hervor.

Im Ablauf
Parse error: syntax error, unexpected '+', expecting ',' or ';' in ...



Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Hadanite Marasek meinte:
> Gregor Kofler schrieb:
>> Funktioniert:
>> define('x', 1+1);
>> define('y', 'a'.'b');
>>
>> Funktioniert nicht:
>>
>> class foo {
>> const x = 1+1;
>> const y = 'a'.'b';
>> }
>>
>> Können Operatoren bei der Definition von Klassenkonstanten prinzipiell
>> nicht verwendet werden, oder überseh ich was?
>
> Das gilt, wenn ich es recht überblicke, für alles, also auch für
> Members. Es geht:
>
> private $foo = NULL;
> private $foo = array();
> private $foo = "foo";
>
>
> Aber nicht:
>
> private $foo = 1+1;
> private $foo = str_replace("fuu", "foo", "This is fuubar");
> private $foo = new Foo();
>

Hmmm. Stimmt. Da ist es mir nur noch nie aufgefallen, da die Vorbelegung
mit "komplexeren" Werten bislang immer im Konstruktor (oder sonstigen
Methoden) erledigt wurde.

Diese Konstanten wollte ich hingegen nur in einer Quasi-Klasse der
Übersichtlichkeit halber zusammenführen.

Danke, Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Gregor Kofler schrieb:
> Funktioniert:
> define('x', 1+1);
> define('y', 'a'.'b');
>
> Funktioniert nicht:
>
> class foo {
> const x =3D 1+1;
> const y =3D 'a'.'b';
> }
>
> Können Operatoren bei der Definition von Klassenkonstanten prinzipiel=
l
> nicht verwendet werden, oder überseh ich was?

Nein, das hast du korrekt erfasst. Klassenkonstanten sind "echte" zu
Kompilierung generierte Konstanten, wohingegen die normalen altbekannten
Konstanten laufzeitgeneriert sind. Dementsprechend sieht es übrigens
auch bei der Performance aus.

OLLi


--
"Kopf abhacken? Hast du wieder Arbeit mit nach Hause gebracht?"
[Medium 103]

Oliver Grätz schrieb:

>Klassenkonstanten sind "echte" zu Kompilierung generierte Konstanten

Die genannten Ausdrücke wären zur Compilezeit problemlos auswertbar, das
ist daher kein Argument, warum es nicht gehen kann. Letztlich also wieder
eine schnell hingeschusterte Implementierung, die hoffentlich irgendwann
noch entsprechend erweitert wird.

--
Wolfgang Fellger

Gregor Kofler schrieb:
> Hmmm. Stimmt. Da ist es mir nur noch nie aufgefallen, da die Vorbelegung
> mit "komplexeren" Werten bislang immer im Konstruktor (oder sonstigen
> Methoden) erledigt wurde.

deswegen gehehn keine Zuweisungen als Membervariablen, Konstanten oder
auch Default Parameter. Sowas gehört in den Konstruktor (da brauchst
dann halt eine Klasse, kein Interface wie unten):

class Konstanten
{
private const A;

public function __construct()
{
$this->A = 1 + 1;
}
}

Nur falls von außen darauf zugreifen willst ohne konkretes Objekt
solltes vielleicht eher eine statische Methode machen, die dir einfach
eine Konstante zurück gibt:

class Konstanten
{
public static function getA()
{
return 1 + 1;
}
}

> Diese Konstanten wollte ich hingegen nur in einer Quasi-Klasse der
> Übersichtlichkeit halber zusammenführen.

Ich empfehle dir ein Interface:

interface Konstanten
{
const A = 1;
const B = 2;
}

Der Vorteil, in jeder Klasse, wo die Konstanten brauchst, kannst das
Interface implementieren:

class meineKlasse implements Konstanten
{
public function __construct()
{
print self::A;
}
}

Finde ich eine sehr schöne Trennung von Konstanten und der
implementierende Klasse. Auch wenn das wohl eher Geschmackssache ist. :)

Hoffe ich konnte dir weiterhelfen.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Oliver Grätz meinte:
> Gregor Kofler schrieb:
>> Funktioniert:
>> define('x', 1+1);
>> define('y', 'a'.'b');
>>
>> Funktioniert nicht:
>>
>> class foo {
>> const x = 1+1;
>> const y = 'a'.'b';
>> }
>>
>> Können Operatoren bei der Definition von Klassenkonstanten prinzipiell
>> nicht verwendet werden, oder überseh ich was?
>
> Nein, das hast du korrekt erfasst. Klassenkonstanten sind "echte" zu
> Kompilierung generierte Konstanten, wohingegen die normalen altbekannten
> Konstanten laufzeitgeneriert sind. Dementsprechend sieht es übrigens
> auch bei der Performance aus.

Ok, danke. Ist also von der Sorte "ist eben so".

Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Christoph Herrmann meinte:

> deswegen gehehn keine Zuweisungen als Membervariablen, Konstanten oder
> auch Default Parameter. Sowas gehört in den Konstruktor (da brauchst
> dann halt eine Klasse, kein Interface wie unten):


[Alternativen gesnippt]

Erklärungen und Alternativen verstehe ich. Es ging mir aber ursprünglich
nur um das konkatenieren (wasfüreinwort...) von Teilen einer
umfangreichen RegEx aus Übersichtlichkeitsgründen.

Gruß, Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Gregor Kofler schrieb:

> Claus Reibenstein meinte:
>
>> Gregor Kofler schrieb:
>>
>>> Funktioniert nicht:
>>>
>>> class foo {
>>> const x = 1+1;
>>> const y = 'a'.'b';
>>> }
>>
>> Definiere "Funktioniert nicht". Fehlermeldung? Falsche Ergebnisse?
>
> Mit "funktioniert nicht" meinte ich, dass diese Konstruktion nicht
> "funktioniert" - deshalb auch meine dahingehende Frage.

Das ist keine Antwort.

> Der Vollständigkeit halber:
>
> Die IDE schreit schon "expecting , or ;" und hebt den Operator hervor.
>
> Im Ablauf
> Parse error: syntax error, unexpected '+', expecting ',' or ';' in ...

Das wollte ich wissen. Damit kann ich was anfangen.

Die Dokumentation zu const erzählt hier etwas von "constant expression",
ohne diesen Begriff genau zu erläutern. An anderen Stellen werden aber
Ausdrücke wie 1+2 als "constant expression" bezeichnet. Also sollten
Deine Ausdrücke hier auch als "constant expression" funktionieren. Hier
scheint also wohl ein Fehler in der Implementierung vorzuliegen.

IMHO ist das ein Fall für einen Bug Report.

Gruß. Claus

Also sprach Gregor Kofler:

> Erklärungen und Alternativen verstehe ich. Es ging mir aber
> ursprünglich nur um das konkatenieren (wasfüreinwort...) von Teilen
> einer umfangreichen RegEx aus Übersichtlichkeitsgründen.

Das kann man doch mit dem x-Modifier sehr schön machen und dabei die
Regechse noch kommentieren:

class Foo
{
const MY_REGEX =
'/ blah # matche "blah"
blah # matche "blah"
blah # matche "blah"
/x';
}

Gruß,
Thomas

Claus Reibenstein meinte:
> Gregor Kofler schrieb:
>
>> Claus Reibenstein meinte:
>>
>>> Gregor Kofler schrieb:
>>>
>>>> Funktioniert nicht:
>>>>
>>>> class foo {
>>>> const x = 1+1;
>>>> const y = 'a'.'b';
>>>> }
>>> Definiere "Funktioniert nicht". Fehlermeldung? Falsche Ergebnisse?
>> Mit "funktioniert nicht" meinte ich, dass diese Konstruktion nicht
>> "funktioniert" - deshalb auch meine dahingehende Frage.
>
> Das ist keine Antwort.

IMO schon. Aber bitte.

> Die Dokumentation zu const erzählt hier etwas von "constant expression",
> ohne diesen Begriff genau zu erläutern. An anderen Stellen werden aber
> Ausdrücke wie 1+2 als "constant expression" bezeichnet. Also sollten
> Deine Ausdrücke hier auch als "constant expression" funktionieren. Hier
> scheint also wohl ein Fehler in der Implementierung vorzuliegen.

Die Dokumentation von Klassenkonstanten erwähnt nichts in der Richtung
und die Beispiele sind "klassisch".

> IMHO ist das ein Fall für einen Bug Report.

Wenn die Antwort von Oliver zutreffend ist, ist es ein Feature.

Gruß, Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Thomas Mlynarczyk meinte:
> Also sprach Gregor Kofler:
>
>> Erklärungen und Alternativen verstehe ich. Es ging mir aber
>> ursprünglich nur um das konkatenieren (wasfüreinwort...) von Teilen
>> einer umfangreichen RegEx aus Übersichtlichkeitsgründen.
>
> Das kann man doch mit dem x-Modifier sehr schön machen und dabei die
> Regechse noch kommentieren:
>
> class Foo
> {
> const MY_REGEX =
> '/ blah # matche "blah"
> blah # matche "blah"
> blah # matche "blah"
> /x';
> }

Ja, an den Extended-Modifier als Workaround habe ich (nachdem die
Verkettung so wie andere Operationen nicht hinhauen) auch schon gedacht.

Verschlechtert sich die Performance einer RegEx mit x-Modifier gegenüber
einer ohne (dramatisch)?

Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Also sprach Gregor Kofler:

> Verschlechtert sich die Performance einer RegEx mit x-Modifier
> gegenüber einer ohne (dramatisch)?

Ich glaube kaum, daß das viel ausmacht. Der RegEx-Parser muß ja nur vorher
den überflüssigen Whitespace sowie die Kommentare wegputzen. Das /ist/
natürlich Zusatzarbeit, sollte aber nicht so drastisch ins Gewicht fallen.
Der Gewinn an Übersichtlichkeit dürfte jedenfalls wichtiger sein. Gerade bei
Regechsen.

Gruß,
Thomas

Wolfgang Fellger schrieb:
> Oliver Grätz schrieb:
>
>> Klassenkonstanten sind "echte" zu Kompilierung generierte Konstanten
>
> Die genannten Ausdrücke wären zur Compilezeit problemlos auswertbar=
, das
> ist daher kein Argument, warum es nicht gehen kann. Letztlich also wied=
er
> eine schnell hingeschusterte Implementierung, die hoffentlich irgendwan=
n
> noch entsprechend erweitert wird.

Von "nicht gehen KANN" habe ich auch nie was gesagt. Ich habe nur
gesagt, dass die Implementierung komplett abweichend (und flotter) und
somit nicht mit der von define() vergleichbar ist. Aktuell werden die
Konstanten wohl so generiert wie in Java "static final" Properties. Und
Properties können in PHP grundsätzlich nicht über Ausdrücke geset=
zt
werden, das ist nicht auf Klassenkonstanten beschränkt. Melde doch die
Bitte, die Sprache in dem Punkt zu verbessern, einfach mal auf
bugs.php.net an!

OLLi

--
"Please tell me you found a coffee bar."
[Jack on LOST 113]

Wolfgang Fellger schrieb:
> Oliver Grätz schrieb:
>
>> Klassenkonstanten sind "echte" zu Kompilierung generierte Konstanten
>
> Die genannten Ausdrücke wären zur Compilezeit problemlos auswertbar, das
> ist daher kein Argument, warum es nicht gehen kann. Letztlich also
> wieder eine schnell hingeschusterte Implementierung, die hoffentlich
> irgendwann noch entsprechend erweitert wird.

Was witzigerweise auch nicht funktioniert ist:

private const foo = 1;

Das mit dem 'hingeschustert' ist wohl zutreffend, aber wir können ja
immer hoffen ... :-)

Peter

Peter Sommerfeld schrieb:
> Wolfgang Fellger schrieb:
>> Oliver Gr=C3=A4tz schrieb:
>>
>>> Klassenkonstanten sind "echte" zu Kompilierung generierte Konstanten
>> Die genannten Ausdr=C3=BCcke w=C3=A4ren zur Compilezeit problemlos aus=
wertbar, das
>> ist daher kein Argument, warum es nicht gehen kann. Letztlich also
>> wieder eine schnell hingeschusterte Implementierung, die hoffentlich
>> irgendwann noch entsprechend erweitert wird.
>
> Was witzigerweise auch nicht funktioniert ist:
>
> private const foo =3D 1;

Klassenkonstanten sind in PHP per Definition public. Die Notiz zu der
Entscheidung auf der Mailing List war glaube ich "Verstecken macht wenig
Sinn bei etwas, was man eh nicht beschreiben kann". Typisch
PHP-Internals: immer pragmatisch. Konzeptionelle =C3=9Cberlegungen machen=

wenig Sinn bei denen; wenn dem so w=C3=A4re, dann w=C3=A4re PHP 5.0 nie o=
hne
Namespace/Package-Unterst=C3=BCtzung rausgekommen...

OLLi


--
User failure. Replace and strike key when ready.

Oliver Grätz schrieb:
> Peter Sommerfeld schrieb:
>> Was witzigerweise auch nicht funktioniert ist:
>>
>> private const foo = 1;
>
> Klassenkonstanten sind in PHP per Definition public. Die Notiz zu der
> Entscheidung auf der Mailing List war glaube ich "Verstecken macht wenig
> Sinn bei etwas, was man eh nicht beschreiben kann".

Den Gedanken verstehe wer will, ich nicht.

> Typisch PHP-Internals: immer pragmatisch. Konzeptionelle Ãœberlegungen
> machen wenig Sinn bei denen; wenn dem so wäre, dann wäre PHP 5.0 nie
> ohne Namespace/Package-Unterstützung rausgekommen...

Das hat nichts mit Pragmatik zu tun sondern mangelndem Durchblick. Aber
was solls: auch damit wie mit vielem anderen muss man leben...

Peter

Peter Sommerfeld schrieb:
>> Klassenkonstanten sind in PHP per Definition public. Die Notiz zu der
>> Entscheidung auf der Mailing List war glaube ich "Verstecken macht wen=
ig
>> Sinn bei etwas, was man eh nicht beschreiben kann".
>
> Den Gedanken verstehe wer will, ich nicht.

In den g=C3=A4ngigen Anwendungen passt das schon. Klassenkonstanten sind =
da
meist Platzhalter f=C3=BCr Optionen, die man grunds=C3=A4tzlich von au=C3=
=9Fen
verwendet (sowas wie PDO::FETCH_ASSOC). Das Konzept ist beschr=C3=A4nkt,
uneinheitlich UND f=C3=BCr 99% der Anwendungen richtig. Ich sage ja:
pragmatisch. Die aktuelle L=C3=B6sung war schnell machbar und sie passt a=
uf
die meisten Anwendungen.

>> Typisch PHP-Internals: immer pragmatisch. Konzeptionelle =C3=9Cberlegu=
ngen
>> machen wenig Sinn bei denen; wenn dem so w=C3=A4re, dann w=C3=A4re PHP=
5.0 nie
>> ohne Namespace/Package-Unterst=C3=BCtzung rausgekommen...
>
> Das hat nichts mit Pragmatik zu tun sondern mangelndem Durchblick. Aber=

> was solls: auch damit wie mit vielem anderen muss man leben...

Bei mir rennst du offene T=C3=BCren ein. Ich habe da auch schon versucht,=
das
Thema zu pushen. Bei den Namespaces sagen die Internals immer wieder,
dass sie schon vor Jahren alle darum gebeten h=C3=A4tten, ihre Klassen mi=
t
einem einzigartigen Prefix zu benennen und dass das reichen w=C3=BCrde (w=
enn
sie damals eine offizielle Prefix-Registry eingerichtet h=C3=A4tten, dann=

h=C3=A4tte das wom=C3=B6glich geklappt...</sarcasm>). Man muss dabei imme=
r daran
denken, dass Rasmus PHP nur als Template-Sprache gedacht hat und der
Meinung ist, den sonstigen Programmcode solle man eh am besten in C
selbst schreiben. Bei PHP m=C3=BCssen aktive Programmierer selbst zum
Evangelist werden und neue Features mit Nachdruck einfordern. So kommen
die Namespaces jetzt wenigstens schon in 5.3 und nicht erst mit dem wohl
stark versp=C3=A4teten PHP6.

OLLi

--
Es mangelte an Antworten, aber der Katalog der Fragen pr=C3=A4sentierte s=
ich
makellos.
[H=C3=B6rspiel "Der Schwarm", 4.13]