Onderwerp: PHP: false, null en '0'

Rene Pijlman wrote:
> Michiel de Roo:
>
>>Nee, helaas mensen. Als ik PHP achter mij laat is dat omdat ik op servlets
>>overstap.
>
>
> Wat mij betreft een prima keuze hoor.
>
>
>>Helaas zijn de hosting kosten daarvoor nog redelijk duur
>
>
> Hé, zit hier een gat in de markt?
>
> Wat zou je bereid zijn te betalen voor hosting van server-side Java
> applicaties, inclusief Tomcat, JBoss, de Apache projecten, een database
> server etc.?
>

Momenteel betaal ik EU 14. Het mag best iets duurder, maar boven de 20
wordt het minder interessant voor de gemiddelde website.

Het hangt ook van de klant af natuurlijk. Als ik een klant krijg die 5000
visits per dag heeft, worden servlets ineens wel een heel stuk
interessanter. Dan zouden de hosting kosten ook zowieso een stuk hoger zijn.

Ik ben ook vooral geinteresseerd in MMBase.

Michiel.

Michiel de Roo:
>Ik ben ook vooral geinteresseerd in MMBase.

Maar MMBase hosting is tegenwoordig toch goed verkrijgbaar?
http://www.backsoft.nl/mmbase/MMBase-hosting.htm
http://www.amaze.nl/products/hosting/
.... om er maar eens een paar te noemen.

Maar ik betwijfel eerlijkgezegd een beetje of zo'n Java-platform zich
leent voor goedkope mass hosting.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman wrote:
> Maar voor ff een scrippie is dat gedoe met strikte signatures soms
> knap lastig. Je verandert wat in een method deep down, die blijkt
> daardoor een andere exception te kunnen throwen en voor je het weet
> moet je op 487 plaatsen de signature aanpassen. Nu weet ik ook wel
> dat je dat in een goed ontworpen systeem moet voorkomen door passende
> abstracties te introduceren, maar dat wil je allemaal niet voor ff
> een scrippie.

Heb je het nou over 'even een scrippie' of over iets met 487 signatures
Maar even serieus: Hoe kun je dit vermijden als je procedureel programmeert?
en waarom kan dat in een OO taal niet op dezelfde manier?

>
> En neem nu zoiets triviaals als een enumerated type. Wat je in Java
> allemaal niet moet programmeren om een equivalent daarvan in een
> class te krijgen... weerzinwekkend. Er zijn boeken, nou je
> hoofdstukken over geschreven.
> http://developer.java.sun.com/develo...a/Chapter5.pdf

Maar daarin worden juist de tekortkomingen van de C enum construct
beschreven, en hoe het gebruik van OO helpt deze te overbruggen.

Groet, Jaap

Jaap Beetstra:
>Rene Pijlman:
>> Je verandert wat in een method deep down, die blijkt
>> daardoor een andere exception te kunnen throwen en voor je het weet
>> moet je op 487 plaatsen de signature aanpassen.

>Hoe kun je dit vermijden als je procedureel programmeert?
>en waarom kan dat in een OO taal niet op dezelfde manier?

Het is volgens mij niet zozeer een kwestie van OO vs. procedureel, maar
van 1) "typed exceptions in signatures" vs. 2) untyped exceptions of 3)
exceptions die geen onderdeel uitmaken van de signature.

En 2 en 3, of 1 samen met de eerder genoemde abstracties van de
programmeur, zijn volgens mij de manieren om de kwestie te vermijden.

>> En neem nu zoiets triviaals als een enumerated type. Wat je in Java
>> allemaal niet moet programmeren om een equivalent daarvan in een
>> class te krijgen... weerzinwekkend. Er zijn boeken, nou je
>> hoofdstukken over geschreven.
>> http://developer.java.sun.com/develo...a/Chapter5.pdf
>
>Maar daarin worden juist de tekortkomingen van de C enum construct
>beschreven, en hoe het gebruik van OO helpt deze te overbruggen.

Hoezo "maar"? Dit doet niets af aan mijn punt over de Java-code die nodig
is om het equivalent van de enum in C te krijgen.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman wrote:
> Het is volgens mij niet zozeer een kwestie van OO vs. procedureel,
> maar van 1) "typed exceptions in signatures" vs. 2) untyped
> exceptions of 3) exceptions die geen onderdeel uitmaken van de
> signature.
>
> En 2 en 3, of 1 samen met de eerder genoemde abstracties van de
> programmeur, zijn volgens mij de manieren om de kwestie te vermijden.

Ok, maar checked excepties zijn geen noodzakelijk onderdeel van OO (ik neem
aan dat je checked bedoelt ipv typed?). En in Java kun je ze altijd nog `of
wrappen in een unchecked exception, `of ze volledig negeren. Dan hoef je de
signature niet te veranderen.
Het al dan niet zinnig zijn van de 'alles is een object' gedachtengang (waar
het eerst over ging) is een andere issue.

>>> En neem nu zoiets triviaals als een enumerated type. Wat je in Java
>>> allemaal niet moet programmeren om een equivalent daarvan in een
>>> class te krijgen... weerzinwekkend. Er zijn boeken, nou je
>>> hoofdstukken over geschreven.
>>> http://developer.java.sun.com/develo...a/Chapter5.pdf
>>
>> Maar daarin worden juist de tekortkomingen van de C enum construct
>> beschreven, en hoe het gebruik van OO helpt deze te overbruggen.
>
> Hoezo "maar"? Dit doet niets af aan mijn punt over de Java-code die
> nodig is om het equivalent van de enum in C te krijgen.

Je claimt dat het hoofdstuk gaat over wat je allemaal moet doen om een
enum-equivalent te krijgen. Het hoofdstuk gaat niet over hoe enums te
simuleren, maar over hoe OO enums kan vervangen/verbeteren. De directe
mapping van een enum is een simpele constante, maar dit is lang zo krachtig
niet. Met weinig moeite kun je in een OO-taal dingen bereiken die je met
enums in een procedurele taal veel meer moeite kosten, en tot hogere
complexiteit leiden.

Groet, Jaap

Jaap Beetstra:
>Het al dan niet zinnig zijn van de 'alles is een object' gedachtengang (waar
>het eerst over ging) is een andere issue.

Had je dit niet gezien? :-)
>>>> Maar goed, ik dwaal af van jouw vraag.

>Het hoofdstuk gaat niet over hoe enums te simuleren, maar over hoe OO enums
>kan vervangen/verbeteren.

OK, het is meer dan een equivalent, dat is waar.

Maar dat dit soort complexe patronen [1] nodig zijn voor een conceptuele
trivialiteit als een type dat bestaat uit een lijstje waarden, vind ik
maar bizar.

[1] "... define a class representing a single element of the enumerated
type, and don’t provide any public constructors. Instead, provide public
static final fields, one for each constant in the enumerated type."

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>Het hoofdstuk gaat niet over hoe enums te simuleren, maar over hoe OO enums
>>kan vervangen/verbeteren.
>
> OK, het is meer dan een equivalent, dat is waar.
>
> Maar dat dit soort complexe patronen [1] nodig zijn voor een conceptuele
> trivialiteit als een type dat bestaat uit een lijstje waarden, vind ik
> maar bizar.

Maar je hebt zo'n complex ding helemaal niet nodig om de enum te
emuleren. Immers:

> [1] "... define a class representing a single element of the enumerated
> type, and don?t provide any public constructors. Instead, provide public
> static final fields, one for each constant in the enumerated type."
>

Enumerated type! In C is dat gewoon altijd een int(?)! Dus als je dat
wilt kan je met

public class EnumFruit
{
private static final int APPEL=0;
private static final int PEER=1;
private static final int BANAAN=2;
}

volstaan.

De classe kan je dan misbruiken als:

public class Foo
{
public static void main(String[] args)
{
switch(args[0])
{
case EnumFruit.APPEL:
System.out.println("arg0 was 0");
break;
default:
System.out.println("arg0 was geen 0");
}
}
}

Mocht je EnumFruit.FOO te veel tik werk vinden dan kan je EnumFruit als
interface bestempelen en die implementen in de Foo classe.

Een leuke URL mbt dit onderwerp:
http://developer.java.sun.com/develo...ava/page1.html

Bevat voorbeelden die wel duidelijk maken dat het verdomd handig is om
de "complexe" methode te implementeren:
<q>
Not only is this legal C:

typedef enum {FUJI, PIPPIN, GRANNY_SMITH} apple_t;
typedef enum {NAVEL, TEMPLE, BLOOD} orange_t;

/* Mixing apples and oranges */
orange_t myFavorite = PIPPIN;

but so is this atrocity:

/* Tasty citrus-flavored applesauce!!! */
orange_t x = (FUJI - PIPPIN)/TEMPLE;
</q>

--

Daniel Tryba

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>> Ik corrigeer mijzelve: welkom builtin non-class types! :-)
>>
>>Waarom zou je dat willen in een (gedeeltelijke) OO taal?
>
> Om te beginnen heb ik het conceptueel moeilijk met het
> alles-is-een-object-idee. Wat zijn immers de attributen van een object in
> zo'n wereld? "Objecten!" hoor ik je denken, maar... enfin je snapt mijn
> Hofstadteriaanse vraagtekens.

Dat snap ik dus niet, ik heb niets met filosofie, je zult het me dus
moeten uitleggen.

> Verder hou ik niet van een opgelegd software-paradigma. Soms wil ik OO
> programmeren, soms traditioneel, soms functioneel en soms wil ik gewoon ff
> een scrippie om wat handigs te doen op mijn computer.

Daar is niet bijzonders aan, die zelfde wensen heeft vrijwel iedere
programmeur.

> Als Java in al die dingen goed was dan gebruikte ik uitsluitend Java.

Ik moet er niet aan denken me zelf slechts 1 taal op te leggen. En 1
taal voor alle momenten lijkt me (tot nu toe) onmogelijk.

> Maar voor ff een scrippie is dat gedoe met strikte signatures soms
> knap lastig. Je verandert wat in een method deep down, die blijkt
> daardoor een andere exception te kunnen throwen en voor je het weet
> moet je op 487 plaatsen de signature aanpassen. Nu weet ik ook wel dat
> je dat in een goed ontworpen systeem moet voorkomen door passende
> abstracties te introduceren, maar dat wil je allemaal niet voor ff een
> scrippie.

Dat is in een procedurele taal niet anders. Als je de return value
veranderd zul je overal moeten checken of die nieuwe (extra) waarde
overal netjes afgevangen wordt.

> En neem nu zoiets triviaals als een enumerated type. Wat je in Java
> allemaal niet moet programmeren om een equivalent daarvan in een class
> te krijgen... weerzinwekkend. Er zijn boeken, nou je hoofdstukken over
> geschreven.
> http://developer.java.sun.com/develo...a/Chapter5.pdf
>
> Is een taal met een builtin enum nou niet veel makkelijker? Mis ik ook
> bij Python trouwens.

Dat kan ik niet bevestigent beantwoorden, zelfs in deze pdf staat al een
simpele Java implementatie van een enum:
<q page='16'>
The typesafe enum pattern has few disadvantages when compared to the
int pattern. Perhaps the only serious disadvantage is that it is more
awkward to aggre- gate typesafe enum constants into sets. With int-based
enums, this is traditionally done by choosing enumeration constant
values, each of which is a distinct positive power of two, and
representing a set as the bitwise OR of the relevant constants:

// B it-flag variant of int enum pattern
public static final int SUIT_CLUBS = 1;
public static final int SUIT_DIAMONDS = 2;
public static final int SUIT_HEARTS = 4;
public static final int SUIT_SPADES = 8;
public static final int SUIT_BLACK = SUIT_CLUBS | SUIT_SPADES;
</q>

> Maar goed, ik dwaal af van jouw vraag. Een goede vraag. Misschien weet
> ik er geen goed antwoord op. Misschien ben ik wel te inflexibel, zoals
> de programmeurs in mijn omgeving die niet konden programmeren zonder
> pointers, terwijl ik niet meer kan programmeren met.

Nou kan ik persoonlijk ook niet programmeren met pointers. Zelf hou ik
dan ook nog eens van static type checking ( if(1) of if("") dienen te
worden vermeden ten voorkeur van eenduidige expressies). Een taal als
Java met zowel objeten en primitieven en statisch types is IMHO een
goede manier waar je in een OO taal geen primitieven wilt (het jongleren
met types (eventueel in container objecten) is een ramp).

Op papier zit C# (heb alle de reference gelezen) er stukken beter uit
wat de voor Java genoemde nadelen betreft, puur omdat daar wel alle
primitieven gewone objecten zijn (bv 1.toString() itt
Integer.toString(1) (kan ook met '""+1' echter dat geeft leuke effecten
als bv: 'a'+1+"foo" (tgv operator overloading )). Er zijn wel weer
andere nadelen zoals operator overloading (maakt dingen onzichtbaar
complexer).

--

Daniel Tryba

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > Maar aan de andere kant is het inderdaad zo dat ik bij alle talen met
> > een expliciete block syntax altijd consequent een bepaalde indentering
> > aanbreng en de haakjes dan in feite overbodig zijn.
>
> Ja en nee: ik hou zelf ook een vrij nette (al zeg ik het zelf) indentering
> aan, maar ik vind expliciete blokscheiders zoals accolades visueel toch
> prettiger.

Het lijkt me vooral lastig als je met code van andere moet werken, in
python is een coding standard nog velen malen belangrijker. En aangezien
de enige goede standaard de standaard van elke onafhankelijke progger is
voorzie ik een probleem.

Verder vind ik het uiterst goor dat de markup van je code de
functionaliteit bepaalt.

--

Daniel Tryba

Rene Pijlman wrote:
> Marcus:
>>Michiel de Roo:
>>> Ik heb inmiddels wel door dat je niet php moet gaan programmeren [...;-)]
>>
>>Moet je misschien toch eens naar perl gaan kijken. Hoewel het even duurt
>>voordat je alles door hebt kan je er daarna best netjes OO in
>>programmeren.
>
> Ik wil hier niet de language advocate uithangen, maar als je overweegt
> naar Perl te kijken _dan_ heb je zeker een reden om eerst naar Python te
> kijken. Python is Perl, maar dan goed.
>
> Zie wat ESR erover zegt in:
> http://www.linuxjournal.com/article.php?sid=3882

Moet zeggen dat t me er wel voor heeft geinteresseerd. Maar eens naar
kijken dan

Mark