[PHP] bestaan enumeraties in PHP?

[Branko Collin]

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

--
Branko Collin
if you reply by e-mail, please change invalid to nl and z to s
(but replies to the news group are preferred)

[Daniel Tryba]

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

Wat heeft een enumeratie te maken met defines? Ik zou voor een
enumeration persoonlijk een array/hash gebruiken in PHP.

--

Daniel Tryba

[Branko Collin]

Daniel Tryba wrote:
> Branko Collin <branko@mixedflavourz.invalid> wrote:
>> Heeft PHP de mogelijkheid om enumeraties (opsommingen) te definieren?
>> (Anders dan door twintig define()'s op te nemen?)
>
> Wat heeft een enumeratie te maken met defines? Ik zou voor een
> enumeration persoonlijk een array/hash gebruiken in PHP.

Een enumeratie is toch een gelijktijdige declaratie van een aantal
constanten? Voor een declaratie van 1 constante gebruik je in PHP de
functie define().

> Ik zou voor een enumeration persoonlijk een array/hash gebruiken in PHP.

Dat kan natuurlijk ook, ik neem even aan dat PHP expressief genoeg is om
een array global te verklaren over alle scripts.

[Daniel Tryba]

Branko Collin <branko@mixedflavourz.invalid> wrote:
>> Wat heeft een enumeratie te maken met defines? Ik zou voor een
>> enumeration persoonlijk een array/hash gebruiken in PHP.
>
> Een enumeratie is toch een gelijktijdige declaratie van een aantal
> constanten?

Ik breng enumeratie in verband met java.util.Enumerations wat het
dichts bij komt in PHP is de for/foreach/list/each functionaliteit.

>> Ik zou voor een enumeration persoonlijk een array/hash gebruiken in PHP.
>
> Dat kan natuurlijk ook, ik neem even aan dat PHP expressief genoeg is om
> een array global te verklaren over alle scripts.

$GLOBALS is een super global array, daar kan je dus je spullen in kwijt.

--

Daniel Tryba

[Marcus]

Daniel Tryba wrote:
> Branko Collin <branko@mixedflavourz.invalid> wrote:
>>> Wat heeft een enumeratie te maken met defines? Ik zou voor een
>>> enumeration persoonlijk een array/hash gebruiken in PHP.
>>
>> Een enumeratie is toch een gelijktijdige declaratie van een aantal
>> constanten?
>
> Ik breng enumeratie in verband met java.util.Enumerations wat het
> dichts bij komt in PHP is de for/foreach/list/each functionaliteit.

Een enumeratie is bijvoorbeeld als je een datatype Fruit hebt, en een
variabele van dat datatype de waarde Appel, Peer of Banaan kan
hebben. In java zou je dat bijvoorbeeld zo doen (wellicht kan het ook zo
in php):

class Fruit{

public static final Fruit APPEL = new Fruit(1);
public static final Fruit PEER = new Fruit(1);
public static final Fruit BANAAN = new Fruit(1);

private int a;
private Fruit(int i){
a = i;
}

public bool equals(Fruit e){
return (this.a = e.a);
}
}


en dan ergens in de code

Fruit x = Fruit.APPEL


en ergens met Fruit x en y

if (x.equals(y)){....}

etc

Mark

[Inca]

Marcus wrote:
>> Ik breng enumeratie in verband met java.util.Enumerations wat het
>> dichts bij komt in PHP is de for/foreach/list/each functionaliteit.
>
> Een enumeratie is bijvoorbeeld als je een datatype Fruit hebt, en een
> variabele van dat datatype de waarde Appel, Peer of Banaan kan
> hebben.

Maar in een taal als php, waar weinig met datatypes wordt gedaan, is het
volgens mij nauwelijks zinnig.
--
Inca
JA - Wel integratie
NEE - Niet met buitenlanders
http://www.poldermodelstickers.nl/

[Marcus]

Inca wrote:
> Marcus wrote:
>>> Ik breng enumeratie in verband met java.util.Enumerations wat het
>>> dichts bij komt in PHP is de for/foreach/list/each functionaliteit.
>>
>> Een enumeratie is bijvoorbeeld als je een datatype Fruit hebt, en een
>> variabele van dat datatype de waarde Appel, Peer of Banaan kan
>> hebben.
>
> Maar in een taal als php, waar weinig met datatypes wordt gedaan, is het
> volgens mij nauwelijks zinnig.

Dat een taal het in de hand werkt slordig te werken hoeft nog geen reden
te zijn dat ook te doen.

Mark

[Branko Collin]

Marcus wrote:
> Inca wrote:
>> Marcus wrote:
>>>> Ik breng enumeratie in verband met java.util.Enumerations wat het
>>>> dichts bij komt in PHP is de for/foreach/list/each functionaliteit.
>>>
>>> Een enumeratie is bijvoorbeeld als je een datatype Fruit hebt, en
>>> een variabele van dat datatype de waarde Appel, Peer of Banaan kan
>>> hebben.
>>
>> Maar in een taal als php, waar weinig met datatypes wordt gedaan, is
>> het volgens mij nauwelijks zinnig.
>
> Dat een taal het in de hand werkt slordig te werken hoeft nog geen
> reden te zijn dat ook te doen.

Ik ben geen echte programmeur, dus doe ik netjes wat me op school is
geleerd.

enum KANFIETSEN=1, KANZWEMMEN=2, KANVETERSSTRIKKEN=4, KANBROODJESSMEREN=8;

$persoon[0] = KANFIETSEN or KANZWEMMEN;
$persoon[1] = KANZWEMMEN or KANVETERSSTRIKKEN;
$persoon[2] = KANVETERSSTRIKKEN or KANBROODJESSMEREN;

// bedenk zelf de loop erbij
if ($persoon[$i] or KANZWEMMEN == $persoon[$i])
{
access_zwembad($persoon[$i]);
}

// Bedankt voor de tips.

[Marcus]

Branko Collin wrote:
> Marcus wrote:
>> Inca wrote:
>>> Marcus wrote:
>>>>> Ik breng enumeratie in verband met java.util.Enumerations wat het
>>>>> dichts bij komt in PHP is de for/foreach/list/each functionaliteit.
>>>>
>>>> Een enumeratie is bijvoorbeeld als je een datatype Fruit hebt, en
>>>> een variabele van dat datatype de waarde Appel, Peer of Banaan kan
>>>> hebben.
>>>
>>> Maar in een taal als php, waar weinig met datatypes wordt gedaan, is
>>> het volgens mij nauwelijks zinnig.
>>
>> Dat een taal het in de hand werkt slordig te werken hoeft nog geen
>> reden te zijn dat ook te doen.
>
> Ik ben geen echte programmeur, dus doe ik netjes wat me op school is
> geleerd.
>
[knip enumeraties]

Je hebt geen OO geleerd?

$persoon[$i].kanzwemmen = true

if ($persoon[$i].kanzwemmen){

etc.

Mark

[Branko Collin]

Marcus wrote:
> Branko Collin wrote:

>> Ik ben geen echte programmeur, dus doe ik netjes wat me op school is
>> geleerd.
>>
> [knip enumeraties]
>
> Je hebt geen OO geleerd?
>
> $persoon[$i].kanzwemmen = true
>
> if ($persoon[$i].kanzwemmen){

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.

Waarschijnlijk een overtrokken reactie van mij, maar leer me nu nog maar
eens nieuwe streken. :-)

[Marcus]

Branko Collin wrote:
>
> Marcus wrote:
>> Branko Collin wrote:
>
>>> Ik ben geen echte programmeur, dus doe ik netjes wat me op school is
>>> geleerd.
>>>
>> [knip enumeraties]
>>
>> Je hebt geen OO geleerd?
>>
>> $persoon[$i].kanzwemmen = true
>>
>> if ($persoon[$i].kanzwemmen){
>
> 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.

Mark

[Daniel Tryba]

Marcus <mark@ijbema.xs4all.nl.invalid> wrote:
>> Ik breng enumeratie in verband met java.util.Enumerations wat het
>> dichts bij komt in PHP is de for/foreach/list/each functionaliteit.
>
> Een enumeratie is bijvoorbeeld als je een datatype Fruit hebt, en een
> variabele van dat datatype de waarde Appel, Peer of Banaan kan
> hebben. In java zou je dat bijvoorbeeld zo doen (wellicht kan het ook zo
> in php):
>
> class Fruit{
> public static final Fruit APPEL = new Fruit(1);
> public static final Fruit PEER = new Fruit(1);
> public static final Fruit BANAAN = new Fruit(1);
[knip]
> }

Aha, enums! Helemaal over het hoofd gezien. Bovenstaande voorbeeld moet
wellicht nog wel te doen zijn in PHP.

--

Daniel Tryba

[Inca]

Daniel Tryba wrote:
>> Dat kan natuurlijk ook, ik neem even aan dat PHP expressief genoeg
>> is om een array global te verklaren over alle scripts.
>
> $GLOBALS is een super global array, daar kan je dus je spullen in
> kwijt.

Nadeel is dat je elke keer zo'n hele lelijke en onoverzichtelijke
constructie krijgt. En dat is vaak een belangrijke reden om constanten te
gebruiken.
Ik heb lang gezocht maar er is niet echt een lekkere oplossing: constanten
kunnen alleen scalars zijn, geen arrays, geen enums. (In Php 5 misschien?)
Dus zit je aan een extra $GLOBAL['arr']['iets'] vast of een extra global in
elke functie.
--
Inca
NEE - Geen buitenlanders
JA - Wel shoarma
http://www.poldermodelstickers.nl/

[Daniel Tryba]

Inca <shadow*movements@wanadoo.nospam.invalid> wrote:
>> $GLOBALS is een super global array, daar kan je dus je spullen in
>> kwijt.
>
> Nadeel is dat je elke keer zo'n hele lelijke en onoverzichtelijke
> constructie krijgt. En dat is vaak een belangrijke reden om constanten te
> gebruiken.
> Ik heb lang gezocht maar er is niet echt een lekkere oplossing: constanten
> kunnen alleen scalars zijn, geen arrays, geen enums. (In Php 5 misschien?)
> Dus zit je aan een extra $GLOBAL['arr']['iets'] vast of een extra global in
> elke functie.

De oplossing zoals Marcus die gaf werkt prima (na enig herschrijven voor
PHP implementatie van OO). Namelijk ongeacht van de daadwerkelijk
oplossing die in een file te includen welke deze oplossing bevat, met
een class kan je dan mooi een namespace met statische waarden
definieren, zo ben je ook meteen van die lelijke defines af.

Veel viezers dan een define bestaat namelijk niet in PHP. Ze zijn immers
globaal, vanwege "backward" compatibility (en dan heb ik het niet over
de tegenpool van forwards compatible) 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.

MAW OO is in dit (en veel andere) gevallen de oplossing.

--

Daniel Tryba

[Inca]

Daniel Tryba 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)

> 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.

> 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.
--
Inca
NEE - Geen kandidaat
JA - Wel nieuwe NAVO topman
http://www.poldermodelstickers.nl/

[Daniel Tryba]

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

[Inca]

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/

[Daniel Tryba]

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::one 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

[inca]

"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::one 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.paamayim-nekudotayim.php )

Groetjes,
Inca

[Branko Collin]

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.

[Branko Collin]

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.

[Daniel Tryba]

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::one 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::one();
?>

--

Daniel Tryba

[Branko Collin]

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-----

[Inca]

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/

[Daniel Tryba]

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]

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

[Branko Collin]

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.
:-,

[Branko Collin]

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,

[Daniel Tryba]

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

[Marcus]

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