Onderwerp: [PHP] bestaan enumeraties in PHP?

Inca <shadow*movements@wanadoo.nospam.invalid> wrote:
>> De oplossing zoals Marcus die gaf werkt prima (na enig herschrijven
>> voor PHP implementatie van OO).
>
> 't Is nogal overkill toch, voor zoiets simpels? Plus dat ik een grote hekel
> heb aan dergelijke dingen - voor mij volstrekt onoverzichtelijk. Je hebt 8
> regels nodig voor iets wat in bv c++ mogelijk is op 1 (Jawel: enums)

8 regels? Dat is inclusief typechecking en construtie van default
objecten...

Als je een enum wilt emuleren heb je voldoende aan:
class Foo
{
var $one=1;
var $bar="bar";
}

>> Veel viezers dan een define bestaat namelijk niet in PHP. Ze zijn
>> immers globaal,
>
> Het zou leuk zijn om dat aan te kunnen geven maar verder vind ik het ideaal.
> Het idee van lokale consts is me ook nog niet helemaal duidelijk eigenlijk.

Lijkt me toch tamelijk evident. Een constante heeft alleen zin binnen
een bepaalde scope. Binnen een functie als:
function Hello()
{
return "World!\n";
}

Boeit het geen ruk dat er iets bestaat als CRYPT_BLOWFISH.

>> word slordig omspringen van
>> ontwikkelaars met "variablen" automatisch gecorrigeerd, bv:
>> $_GET[foob] wordt gecorrigeerd naar $_GET['foob'] indien er geen
>> constante genaamt 'foob' is, en alleen primitieven bevatten.
>
> Dat laatste (alleen primitieven) is een groot probleem, voor het eerste
> wordt netjes gewaarschuwd.

Er is vrijwel niemand die error reporting op een dusdanig niveau zet dat
het opvalt, dat is makkelijk te achterhalen aan de vragen in deze groep.

--

Daniel Tryba

Daniel Tryba wrote:
> Als je een enum wilt emuleren heb je voldoende aan:
> class Foo
> {
> var $one=1;
> var $bar="bar";
> }

True, maar dan moet je nog immer in elke functie je object importeren met
global of aanmaken met new.

>> Het zou leuk zijn om dat aan te kunnen geven maar verder vind ik het
>> ideaal. Het idee van lokale consts is me ook nog niet helemaal
>> duidelijk eigenlijk.
>
> Lijkt me toch tamelijk evident. Een constante heeft alleen zin binnen
> een bepaalde scope. Binnen een functie als:
> function Hello()
> {
> return "World!\n";
> }
>
> Boeit het geen ruk dat er iets bestaat als CRYPT_BLOWFISH.

Dat is net het omgekeerde: een globale die niet local is. CRYPT_BLOWFISH is
een globale constante om het beschikbaar te kunnen maken in verschillende
(eventuele eigen) functies en uitbreidingen.
Maar dat bedoelde ik niet. Ik bedoelde meer wat je hebt aan een constant die
een scope van 1 functie heeft. Dan kun je net zo goed een variabele nemen.
De constants zijn juist makkelijk om waarden door te geven door je hele
applicatie. Binnen de beperkte ruimte van 1 functie is het minder
noodzakelijk om via een constant te voorkomen dat je waarde wordt veranderd,
binnen een uitgebreide applicatie van meerdere files en libs etc is dat veel
belangrijker.

>> Dat laatste (alleen primitieven) is een groot probleem, voor het
>> eerste wordt netjes gewaarschuwd.
>
> Er is vrijwel niemand die error reporting op een dusdanig niveau zet
> dat het opvalt, dat is makkelijk te achterhalen aan de vragen in deze
> groep.

Die error-reporting staat daar standaard op. Dat mensen dat uitzetten,
tsja...
Het maakt mij niet uit of het nou een notice of een warning of een error
geeft, eerlijk gezegd vind ik het prettig als php een beetje probeert
sommige fouten op te vangen.
We leven in een imperfecte wereld....
--
Inca
NEE - Geen buitenlanders
JA - Wel shoarma
http://www.poldermodelstickers.nl/

Inca <shadow*movements@wanadoo.nospam.invalid> wrote:
>> Als je een enum wilt emuleren heb je voldoende aan:
>> class Foo
>> {
>> var $one=1;
>> var $bar="bar";
>> }
>
> True, maar dan moet je nog immer in elke functie je object importeren met
> global of aanmaken met new.

Nope. De hierboven gedefineerde waarden zijn statisch, vandaar dat ik
ook nog vermelde dat je die moet aanroepen met Foo:ne en niet
$foo->one (waar $foo=new Foo() het enige wat je moet doen is de classe
Foo definieren.

>>> Het idee van lokale consts is me ook nog niet helemaal
>>> duidelijk eigenlijk.
>>
>> Lijkt me toch tamelijk evident. Een constante heeft alleen zin binnen
>> een bepaalde scope. Binnen een functie als:
>> function Hello()
>> {
>> return "World!\n";
>> }
>>
>> Boeit het geen ruk dat er iets bestaat als CRYPT_BLOWFISH.
>
> Dat is net het omgekeerde: een globale die niet local is. CRYPT_BLOWFISH is
> een globale constante om het beschikbaar te kunnen maken in verschillende
> (eventuele eigen) functies en uitbreidingen.

De waarde van CRYPT_BLOWFISH is alleen interessant indien je
daadwerkelijk iets met crypto aan het doen bent, Cypto::hasBlowfish
lijkt me beter op z'n plaats op zulke momenten.

Immers ik kan straffeloos in een functie:

echo 'de integer variabele $foo is';
if($foo==SA_ALL)
{
echo ' niet';
}
echo 'gelijk aan '.SA_ALL."\n";

Geen hond die weet wat SA_ALL betekent als hij het stukje code leest, je
kan vaststellen wat de waarde van SA_ALL daadwerkelijk is, maar waar het
vandaan komt en wat de betekenis is kan alleen door de source om te
spitten (SA_ALL komt overigens uit de imap module).

> Maar dat bedoelde ik niet. Ik bedoelde meer wat je hebt aan een constant die
> een scope van 1 functie heeft. Dan kun je net zo goed een variabele nemen.

Ligt eraan, als het een constante dient te zijn dan kan je de waarde
beter niet variabel maken. Dient het ding wel variabel te zijn maar een
default waarde te hebben dan kan je dat het best regelen met een default
voor de var in de functie definitie:

function Foo($foo='bar')
{
...
}

> De constants zijn juist makkelijk om waarden door te geven door je hele
> applicatie. Binnen de beperkte ruimte van 1 functie is het minder
> noodzakelijk om via een constant te voorkomen dat je waarde wordt veranderd,
> binnen een uitgebreide applicatie van meerdere files en libs etc is dat veel
> belangrijker.

Resulterent in een berg spagetti IMHO.

>>> Dat laatste (alleen primitieven) is een groot probleem, voor het
>>> eerste wordt netjes gewaarschuwd.
>>
>> Er is vrijwel niemand die error reporting op een dusdanig niveau zet
>> dat het opvalt, dat is makkelijk te achterhalen aan de vragen in deze
>> groep.
>
> Die error-reporting staat daar standaard op. Dat mensen dat uitzetten,
> tsja...

Nope, de INSTALL van php-4.3.4 zegt:
<q>
Next you must copy php.ini-dist to the appropriate place (normally
/usr/local/lib/php.ini) and edit it as necessary to set PHP options.
</q>

En daarin staat:
daniel@localhost:/tmp/php-4.3.4$ grep E_ALL php.ini-dist | grep -v '^;'
error_reporting = E_ALL & ~E_NOTICE

--

Daniel Tryba

"Daniel Tryba" wrote
> >> Als je een enum wilt emuleren heb je voldoende aan:
> >> class Foo
> >> {
> >> var $one=1;
> >> var $bar="bar";
> >> }
[...]
> Nope. De hierboven gedefineerde waarden zijn statisch, vandaar dat ik
> ook nog vermelde dat je die moet aanroepen met Foo:ne en niet
> $foo->one (waar $foo=new Foo() het enige wat je moet doen is de classe
> Foo definieren.

Weet je dat wel zeker? Ik krijg steeds foutmeldingen, en in de documentatie
lees ik:
"There are class functions, but there are no class variables. In fact, there
is no object at all at the time of the call. Thus, a class function may not
use any object variables (but it can use local and global variables), and it
may no use $this at all. "
( http://nl.php.net/manual/en/keyword....ekudotayim.php )

Groetjes,
Inca

Marcus wrote:
> Branko Collin wrote:

>> Jawel, maar dat heb ik altijd een slecht systeem gevonden. Vooral
>> het idee van data hiding lijkt nogal zwaar te steunen op de (over
>> het algemeen 95% afwezige) documenteerkwaliteiten van degene die de
>> objecten bedenkt en implementeert.
>
> Over het algemeen documenteert OO zichzelf meer dan gewoon
> procedureel. Ik kan de meeste objecten in een keer overzien, dat is
> bij een lange listing van honderden regels wel anders.

Tijden veranderen. Toen ik OOP geleerd kreeg, was het proprietary-denken
redelijk ingeburgerd geraakt. Het idee wat toen in was, was dat je
gecompileerde modules kreeg, waarvan je alleen de interfaces kende, niet de
rest van de code. Wat een object bevatte en welke methodes je erop kon
gebruiken, bleek alleen uit de handleiding.

Uiteraard is in gevallen waar je de broncode kunt zien (aangenomen dat die
een beetje netjes is geschreven) de noodzaak van documentatie wat minder.
Maar omdat ik me sinds mijn studie nauwelijks meer met OOP heb bezig
gehouden, zit ik nog steeds met die idee fixe dat objecten black boxes zijn
waarbij je maar een gooi moet doen om te raden hoe ze ervan binnen uitzien.

Inca wrote:
> Daniel Tryba wrote:
>> De oplossing zoals Marcus die gaf werkt prima (na enig herschrijven
>> voor PHP implementatie van OO).

Inderdaad, een heel elegant alternatief. Ik zat me blind te staren op
voorgebouwde bibliotheken waar de objecten in verborgen werden, maar met
open source of geinterpreteerde talen heb je dat probleem natuurlijk niet:
daar kun je gewoon in de broncode zien hoe het object werkt.

> 't Is nogal overkill toch, voor zoiets simpels? Plus dat ik een grote
> hekel heb aan dergelijke dingen - voor mij volstrekt
> onoverzichtelijk. Je hebt 8 regels nodig voor iets wat in bv c++
> mogelijk is op 1 (Jawel: enums)

Ach, of je nou

ENUM APPEL=1, PEER=2, KERS=4;

doet of

$appel=1;
$peer=2;
$kers=4;

maakt ook niet zoveel uit.

inca <inca@invalid.invalid> wrote:
>> >> Als je een enum wilt emuleren heb je voldoende aan:
>> >> class Foo
>> >> {
>> >> var $one=1;
>> >> var $bar="bar";
>> >> }
> [...]
>> Nope. De hierboven gedefineerde waarden zijn statisch, vandaar dat ik
>> ook nog vermelde dat je die moet aanroepen met Foo:ne en niet
>> $foo->one (waar $foo=new Foo() het enige wat je moet doen is de classe
>> Foo definieren.
>
> Weet je dat wel zeker? Ik krijg steeds foutmeldingen, en in de documentatie
> lees ik:
> "There are class functions, but there are no class variables. In fact, there
> is no object at all at the time of the call. Thus, a class function may not
> use any object variables (but it can use local and global variables), and it
> may no use $this at all. "

Verrek. Je hebt gelijk... Gelukkig wordt er in de volgende versie van
PHP flink ontwikkeld aan de OO implemetatie.

Maar daarmee wordt het class equiv van een enumerator dus:
<?php
class Foo
{
funtion one()
{
return 1;
}

funtion bar()
{
return "bar";
}
}

echo Foo:ne();
?>

--

Daniel Tryba

Branko Collin wrote:
> Heeft PHP de mogelijkheid om enumeraties (opsommingen) te definieren?
> (Anders dan door twintig define()'s op te nemen?)

Om in mijn behoefte te voorzien heb ik de volgende bibliotheek gemaakt,
maar als anderen hem nuttig vinden, gebruik naar hartelust (en naar de
licentie). Hij is ook te vinden op
<http://www.mixedflavours.nl/develop/php_enumlib.zip>. Aanvullingen,
correcties en overige verbeteringen zie ik graag tegemoet.

-----begin enumlib.php-----
<?php

/*
enumblib.php v. 0.1.

Copyright 2003 Mixed Flavours, Amsterdam.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/

define('ENUM_TYPE_LINEAR',1);
define('ENUM_TYPE_EXPONENTIAL',2);

function el_define()
{
// Usage:
// el_define(Startvalue, Type, Constant 1[, constant 2[, ...[,
constant n]]])
// Startvalues have different meanings depending on type:
// ENUM_TYPE_LINEAR: the first constant will be assigned the startvalue
// ENUM_TYPE_EXPONENTIAL: the first constant will be assigned
2^startvalue
// Existing constants passed as constant names will be overwritten
$numargs = func_num_args();
if ($numargs < 4) {return false;}
$start = func_get_arg(0);
$type = func_get_arg(1);
$length = $numargs - 2;
for ($i=0; $i<$length; $i++)
{
$constant_name = func_get_arg($i+2);
if ($type==2)
{
// Powers of 2
$constant_value = pow(2,($start+$i));
}
else
{
// Otherwise, assume linear increment
$constant_value = $start + $i;
}
define($constant_name, $constant_value);
}
return true;
}

/* The following functions may be useful when used with an exponential
enumeration. The advantage of this type of enumeration is that you can
store
a lot of boolean values (is_woman, is_number, may_write, access_root, etc.)
into one combined value, using el_add(), then check using el_test() whether
the combined value contains a member property. */

function el_test($a,$b)
{
// Tests if b is in a
// Example:
// a = 1 + 4 + 16 = 21
// b = 1
// el_test(21,1) = true
// b = 2
// el_test(21,2) = false
return (($a | $b)==$a);
}

function el_add()
{
// All arguments are values
// the function returns false if no values were supplied
// Usage:
// $combined = el_add(CONSTANT[, CONSTANT[, CONSTANT[, ...]]);
$numargs = func_num_args();
$result = 0;
if ($numargs < 1) {return false;}
for ($i=0; $i<$numargs; $i++)
{
$result = $result | func_get_arg($i);
}
return $result;
}

?>
-----einde enumlib.php-----

Branko Collin wrote:
> function el_define()
> {
> // Usage:
> // el_define(Startvalue, Type, Constant 1[, constant 2[, ...[,
> constant n]]])

Het heeft wel een leuk Mexicaans tintje dat 'el_' (-:

> // Existing constants passed as constant names will be overwritten

Het proberen van een 'define' voor een constante die al bestaat geeft dacht
ik een warning - de constante behoudt zijn oude waarde. (Niet getest)

--
Inca
NEE - Vrijheid is niet te koop
JA - Wel voor olie
http://www.poldermodelstickers.nl/

Branko Collin <branko@mixedflavourz.invalid> wrote:
> Om in mijn behoefte te voorzien heb ik de volgende bibliotheek gemaakt,
> maar als anderen hem nuttig vinden, gebruik naar hartelust (en naar de
> licentie). Hij is ook te vinden op
> <http://www.mixedflavours.nl/develop/php_enumlib.zip>. Aanvullingen,
> correcties en overige verbeteringen zie ik graag tegemoet.

De enige fout is IMHO je 'if($type==x)'. Ik zou daar een switch van
maken, verder vind ik persoonlijk meerdere exit points goor.

BTW als mijn posting een beetje raar uitziet is dat tgv een kop water
over mijn toetsenbord

--- enumlib.php.orig 2003-11-29 04:57:03.000000000 +0100
+++ enumlib.php 2003-11-29 05:02:37.000000000 +0100
@@ -31,27 +31,48 @@
// ENUM_TYPE_LINEAR: the first constant will be assigned the startvalue
// ENUM_TYPE_EXPONENTIAL: the first constant will be assigned 2^startvalue
// Existing constants passed as constant names will be overwritten
+ $rc=true;
$numargs = func_num_args();
- if ($numargs < 4) {return false;}
- $start = func_get_arg(0);
- $type = func_get_arg(1);
- $length = $numargs - 2;
- for ($i=0; $i<$length; $i++)
+ if ($numargs < 4)
{
- $constant_name = func_get_arg($i+2);
- if ($type==2)
+ $rc=false;
+ }
+ else
+ {
+ $start = func_get_arg(0);
+ $type = func_get_arg(1);
+ $length = $numargs - 2;
+ for ($i=0; $i<$length; $i++)
+ {
+ $constant_name = func_get_arg($i+2);
+
+ switch($type)
+ {
+ case ENUM_TYPE_EXPONENTIAL:
+ // Powers of 2
+ $constant_value = pow(2,($start+$i));
+ break;
+ case ENUM_TYPE_LINEAR:
+ // Otherwise, assume linear increment
+ $constant_value = $start + $i;
+ break;
+ default:
+ $constant_value=false;
+ $rc=false;
+ break;
+ }
+
+ if($constant_value!==false && defined($constant_name)!==false)
{
- // Powers of 2
- $constant_value = pow(2,($start+$i));
+ define($constant_name, func_get_arg($i+2));
}
- else
+ else
{
- // Otherwise, assume linear increment
- $constant_value = $start + $i;
+ $rc=false;
}
- define($constant_name, $constant_value);
+ }
}
- return true;
+ return $rc;
}

/* The following functions may be useful when used with an exponential

--

Daniel Tryba

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl> wrote:

Whaahooo:
> + if($constant_value!==false && defined($constant_name)!==false)
if($constant_value!==false && defined($constant_name)===false)

Immers zoals Inca alvermelde
<q src='http://nl2.php.net/manual/en/language.constants.php'>
Constants may not be redefined or undefined once they have been set
</q>

--

Daniel Tryba

Inca wrote:
> Branko Collin wrote:
>> function el_define()
>> {
>> // Usage:
>> // el_define(Startvalue, Type, Constant 1[, constant 2[, ...[,
>> constant n]]])
>
> Het heeft wel een leuk Mexicaans tintje dat 'el_' (-:
>
>> // Existing constants passed as constant names will be overwritten
>
> Het proberen van een 'define' voor een constante die al bestaat geeft
> dacht ik een warning - de constante behoudt zijn oude waarde. (Niet
> getest)

Ge hebt gelijk. Ik zal de handleiding wel ondersteboven hebben gehouden.
:-,

Daniel Tryba wrote:
> Branko Collin <branko@mixedflavourz.invalid> wrote:
>> Om in mijn behoefte te voorzien heb ik de volgende bibliotheek
>> gemaakt, maar als anderen hem nuttig vinden, gebruik naar hartelust
>> (en naar de licentie). Hij is ook te vinden op
>> <http://www.mixedflavours.nl/develop/php_enumlib.zip>. Aanvullingen,
>> correcties en overige verbeteringen zie ik graag tegemoet.
>
> De enige fout is IMHO je 'if($type==x)'. Ik zou daar een switch
> van maken,

Ik vind dat de syntax van een switch over het algemeen te zeer uitnodigt
tot het maken van fouten, en de ruimtewinst ten opzichte van
if-elseif-else-constructies is marginaal. Wel is het natuurlijk zo dat je
semantisch correct zit met een switch-statement. :-)

> verder vind ik persoonlijk meerdere exit points goor.

Daar kan ik me wel iets bij voorstellen.

Is $rc een generieke naam voor een returnwaarde? Waar staat het voor?

bedankt voor je aanvullingen,

Branko Collin <branko@mixedflavourz.invalid> wrote:
> Ik vind dat de syntax van een switch over het algemeen te zeer uitnodigt
> tot het maken van fouten, en de ruimtewinst ten opzichte van
> if-elseif-else-constructies is marginaal. Wel is het natuurlijk zo dat je
> semantisch correct zit met een switch-statement. :-)

Het ging me meer om het feit dat je checkte of $type==2 ipv
$type==EEN_CONSTANTE

>> verder vind ik persoonlijk meerdere exit points goor.
> Daar kan ik me wel iets bij voorstellen.
>
> Is $rc een generieke naam voor een returnwaarde? Waar staat het voor?

Ik associeer he met ReturnCode.

--

Daniel Tryba

Branko Collin wrote:
> Marcus wrote:
>> Branko Collin wrote:
>
>>> Jawel, maar dat heb ik altijd een slecht systeem gevonden. Vooral
>>> het idee van data hiding lijkt nogal zwaar te steunen op de (over
>>> het algemeen 95% afwezige) documenteerkwaliteiten van degene die de
>>> objecten bedenkt en implementeert.
>>
>> Over het algemeen documenteert OO zichzelf meer dan gewoon
>> procedureel. Ik kan de meeste objecten in een keer overzien, dat is
>> bij een lange listing van honderden regels wel anders.
>
> Tijden veranderen. Toen ik OOP geleerd kreeg, was het proprietary-denken
> redelijk ingeburgerd geraakt. Het idee wat toen in was, was dat je
> gecompileerde modules kreeg, waarvan je alleen de interfaces kende, niet de
> rest van de code. Wat een object bevatte en welke methodes je erop kon
> gebruiken, bleek alleen uit de handleiding.
>
> Uiteraard is in gevallen waar je de broncode kunt zien (aangenomen dat die
> een beetje netjes is geschreven) de noodzaak van documentatie wat minder.
> Maar omdat ik me sinds mijn studie nauwelijks meer met OOP heb bezig
> gehouden, zit ik nog steeds met die idee fixe dat objecten black boxes zijn
> waarbij je maar een gooi moet doen om te raden hoe ze ervan binnen uitzien.

Dat kan natuurlijk ook. Waar ik op doelde is dat in goed OO programmeren
(volgens de definitie van de uni hier ) methods maar uit enkele
regels bestaan (je hebt natuurlijk wel eens uitzonderingen voor grote
algoritmes, maar dat moeten uitzonderingen blijven.

Mark