|
| Hvad synes I om den her måde at lave datab~ Fra : Christian Hvid |
Dato : 17-11-04 15:33 |
|
Hej gruppe.
Jeg har lige siddet og puslet med en ide, jeg har hugget fra
webapplikationsframeworket OpenACS.
Ideen går på at bruge dynamisk evaluering til at introducere resultatet af
et databasekald som variable i den kaldende kode.
Så følgende kode:
db_one_row ("SELECT name, number FROM people LIMIT 1");
Vil introducere variablene name og number, så jeg bagefter kan skrive:
echo $name;
echo $number;
I stedet for at skulle skrive noget i retningen af:
$rows = mysql_query("SELECT name, number FROM people LIMIT 1");
$row = mysql_fetch_array($rows);
$name = $row[0];
$number = $row[1];
echo $name;
echo $number;
Hvad synes I? Er det her godt eller skidt?
Min implementation findes her:
http://vredungmand.dk/programming/ez-db-access/index.html
-- Christian
| |
Troels Arvin (17-11-2004)
| Kommentar Fra : Troels Arvin |
Dato : 17-11-04 15:37 |
|
On Wed, 17 Nov 2004 15:33:05 +0100, Christian Hvid wrote:
> Ideen går på at bruge dynamisk evaluering til at introducere resultatet af
> et databasekald som variable i den kaldende kode.
>
> Så følgende kode:
>
> db_one_row ("SELECT name, number FROM people LIMIT 1");
>
> Vil introducere variablene name og number, så jeg bagefter kan skrive:
>
> echo $name;
> echo $number;
Jeg kan ikke se noget problem i det, som en måde at gøre det lidt
lettere/hurtigere at kode.
Man kunne overveje ikke blot at introducere $name og $number, men også
$HTMLname og $HTMLnumber, som var klar til at blive benyttet i
HTML-sammehæng (kørt gennem htmlspecialchars()). Og fx. også $SQLname
og $SQLnumber der var klar til at blive brugt i SQL-udtryk (kørt gennem
relevant DBMS-escaping funktion). Den slags har jeg nogle gange selv
praktiseret. Hvis de afledte HTML/SQL-varianter ligger lige ved
fingerspidserne, er der større chance for, at man rent faktisk får kodet
sikkert uden om SQL injection og cross-site scripting sikkerhedsproblemer.
--
Greetings from Troels Arvin, Copenhagen, Denmark
| |
Christian Joergensen (17-11-2004)
| Kommentar Fra : Christian Joergensen |
Dato : 17-11-04 16:06 |
|
On Wed, 17 Nov 2004 15:33:05 +0100, Christian Hvid wrote:
> db_one_row ("SELECT name, number FROM people LIMIT 1");
>
> Vil introducere variablene name og number, så jeg bagefter kan skrive:
>
> echo $name;
> echo $number;
Generelt set, kan jeg ikke lide at variabler i det aktuelle virkefelt
bliver aendret uden at jeg direkte selv er skyld i det.
Det er ikke klart (for en udenforstaaende) at du efter et kald til
db_one_row() vil have nogle ekstra magiske variabler (som evt. overskriver
allerede brugte variabler?).
Jeg ville nok foretraekke at returnere en eller anden datastruktur, du
nemt kunne hive data ud fra.
$person = db_one_row ("SELECT name, number FROM people LIMIT 1");
echo $person->name;
echo $person->number;
Saa er det (efter min mening) langt mere klart hvad det er der foregaar :)
--
Christian Jørgensen | Codito, Ergo Sum
http://www.razor.dk |
| |
Janf (17-11-2004)
| Kommentar Fra : Janf |
Dato : 17-11-04 17:46 |
|
Christian Joergensen wrote:
> On Wed, 17 Nov 2004 15:33:05 +0100, Christian Hvid wrote:
>
>
>>db_one_row ("SELECT name, number FROM people LIMIT 1");
>>
>>Vil introducere variablene name og number, så jeg bagefter kan skrive:
>>
>>echo $name;
>>echo $number;
>
>
> Generelt set, kan jeg ikke lide at variabler i det aktuelle virkefelt
> bliver aendret uden at jeg direkte selv er skyld i det.
Fornuftig indvending. Dit forslag giver et mere rent snit.
På den anden side, kan man betragte Christians forslag som en slags
udvidet syntaks. Variablene bliver jo faktisk angivet i parametrene til
db_one_row. Og det er en kraftig forenkling.
>
> Det er ikke klart (for en udenforstaaende) at du efter et kald til
> db_one_row() vil have nogle ekstra magiske variabler (som evt. overskriver
> allerede brugte variabler?).
Lige som man ikke kan forstå db_one_row uden at have fået en forklaring,
kan man ikke forstå funktioner med regulære udtryk uden at have fået dem
forklaret. Det er altså ikke noget nyt.
Det nye er, at funktionen har sideeffekter (bivirkninger) idet den
ændrer i globale variable. Det er sædvanligvis en dårlig ide, men
personlig vil jeg synes, at gevinsten ved at gøre det i dette tilfælde
er stor nok til at det er i orden.
Alternativt kunne følgende syntax sikkert stille puritanere tilfreds:
db_one_row ("SELECT name, number FROM people LIMIT 1", $name, $number);
For så er variablene ikke længere "magiske".
--
Jan Fjeldmark mailto:janf@janf.dk http://janf.dk/
Hvad du end tror du er, så er du altid meget mere.
| |
Christian Hvid (17-11-2004)
| Kommentar Fra : Christian Hvid |
Dato : 17-11-04 19:43 |
|
"Janf" <janf@janf.dk> wrote in message
news:419b805e$0$227$edfadb0f@dread11.news.tele.dk...
> Christian Joergensen wrote:
> ...
>
> Det nye er, at funktionen har sideeffekter (bivirkninger) idet den
> ændrer i globale variable. Det er sædvanligvis en dårlig ide, men
> personlig vil jeg synes, at gevinsten ved at gøre det i dette tilfælde
> er stor nok til at det er i orden.
Præcist.
Den oprindelige udgave var lavet i TCL, hvor man eksplicit kan gå et antal
skridt op i skop. I den her PHP-udgave er jeg nødt til (såvidt jeg kan se)
at smide dem op i det globale skop. Enten er variabel lokal eller også er
den global. Selv med eval kan jeg ikke komme op i det kaldende skop.
| |
Christian Hvid (17-11-2004)
| Kommentar Fra : Christian Hvid |
Dato : 17-11-04 20:10 |
|
"Janf" <janf@janf.dk> wrote in message
news:419b805e$0$227$edfadb0f@dread11.news.tele.dk...
> Christian Joergensen wrote:
> ...
> Alternativt kunne følgende syntax sikkert stille puritanere tilfreds:
> db_one_row ("SELECT name, number FROM people LIMIT 1", $name, $number);
>
> For så er variablene ikke længere "magiske".
Godt forslag. Men jeg ville gerne helt udover at definere variablen i andet
end SQL-statementet. Så magi skal der til.
| |
Christian Hvid (17-11-2004)
| Kommentar Fra : Christian Hvid |
Dato : 17-11-04 20:08 |
|
Jeg vendt ideen før med en kammerat. Og det løser udmærket problemet med
global/lokal skop. Men er efter min mening mindre elegant.
I det her tilfælde kan man tale om at funktionskaldet returnerer et
menigsfuldt objekt (en person):
$person = db_one_row ("SELECT name, number FROM people LIMIT 1");
Men det er ikke altid tilfældet, og man ville tit få et resultatobjekt man
ikke skulle bruge til andet end at dotte sig igennem for at få det egentlige
resultat:
$result = db_one_row ("SELECT SUM(total) AS total_revenue FROM orders");
echo $result->total_revenue;
Kontra:
db_one_row ("SELECT SUM(total) AS total_revenue FROM orders");
echo $total_revenue;
"Christian Joergensen" <mail@razor.dk> wrote in message
news:pan.2004.11.17.15.05.30.871893@razor.dk...
> On Wed, 17 Nov 2004 15:33:05 +0100, Christian Hvid wrote:
>
> > db_one_row ("SELECT name, number FROM people LIMIT 1");
> >
> > Vil introducere variablene name og number, så jeg bagefter kan skrive:
> >
> > echo $name;
> > echo $number;
>
> Generelt set, kan jeg ikke lide at variabler i det aktuelle virkefelt
> bliver aendret uden at jeg direkte selv er skyld i det.
>
> Det er ikke klart (for en udenforstaaende) at du efter et kald til
> db_one_row() vil have nogle ekstra magiske variabler (som evt. overskriver
> allerede brugte variabler?).
>
> Jeg ville nok foretraekke at returnere en eller anden datastruktur, du
> nemt kunne hive data ud fra.
>
> $person = db_one_row ("SELECT name, number FROM people LIMIT 1");
> echo $person->name;
> echo $person->number;
>
> Saa er det (efter min mening) langt mere klart hvad det er der foregaar :)
>
> --
> Christian Jørgensen | Codito, Ergo Sum
> http://www.razor.dk |
>
| |
Christian Hvid (17-11-2004)
| Kommentar Fra : Christian Hvid |
Dato : 17-11-04 20:14 |
|
"Christian Joergensen" <mail@razor.dk> wrote in message
news:pan.2004.11.17.15.05.30.871893@razor.dk...
> On Wed, 17 Nov 2004 15:33:05 +0100, Christian Hvid wrote:
> Det er ikke klart (for en udenforstaaende) at du efter et kald til
> db_one_row() vil have nogle ekstra magiske variabler (som evt. overskriver
> allerede brugte variabler?).
Det kræver selvfølgelig at man ved hvordan db_one_row fungerer, før man kan
forstå hvad der foregår.
Men man kan sagtens skrive:
db_one_row ("SELECT name AS my_little_variable FROM people LIMIT 1");
Og så vil kun my_little_variable blive løfte op. Og ikke andet.
| |
Jacob Atzen (17-11-2004)
| Kommentar Fra : Jacob Atzen |
Dato : 17-11-04 18:52 |
|
On 2004-11-17, Christian Hvid <chvid@acm.org> wrote:
> Så følgende kode:
>
> db_one_row ("SELECT name, number FROM people LIMIT 1");
>
> Vil introducere variablene name og number, så jeg bagefter kan skrive:
>
> echo $name;
> echo $number;
>
> I stedet for at skulle skrive noget i retningen af:
>
> $rows = mysql_query("SELECT name, number FROM people LIMIT 1");
> $row = mysql_fetch_array($rows);
> $name = $row[0];
> $number = $row[1];
> echo $name;
> echo $number;
>
> Hvad synes I? Er det her godt eller skidt?
Jeg synes dit modeksempel virker lige lovlig konstrueret. Det ville
sagtens kunne gøres smartere, f.eks. som Christian J. nævner.
Derudover synes jeg, det er en rigtig dårlig ide, at reducere
læsbarheden for at lette tastearbejdet, og tricks du laver her reducerer
læsbarheden markant. I min verden er kodens læsbarhed klart vigtigere
end programmørens arbejde med at taste, da koden bliver læst mere end
den bliver skrevet. I forlængelse af dette kan man nævne, at
effektiviteten hvormed man kan fejlsøge programmer ofte hænger kraftigt
sammen med læsbarheden af koden.
Selv i det tilfælde, hvor læseren er bekendt med semantikken for
db_one_row() opstår der problemer i forbindelse med udviklingsværktøjet.
Man kan f.eks. ikke af en syntax highlighting se, hvor $name bliver
defineret og en søgning efter $name vil heller ikke finde frem til
definitionen.
--
Med venlig hilsen
- Jacob Atzen
| |
Christian Hvid (17-11-2004)
| Kommentar Fra : Christian Hvid |
Dato : 17-11-04 20:08 |
|
"Jacob Atzen" <jacob@aub.dk> wrote in message
news:slrncpn3u2.8i6.jacob@morpheus.aub.dk...
> ...
> Selv i det tilfælde, hvor læseren er bekendt med semantikken for
> db_one_row() opstår der problemer i forbindelse med udviklingsværktøjet.
> Man kan f.eks. ikke af en syntax highlighting se, hvor $name bliver
> defineret og en søgning efter $name vil heller ikke finde frem til
> definitionen.
Du har samme problem ved den anden løsning, da de to felter på det returnede
objekt også bliver defineret på kørselstidspunktet.
| |
Janf (17-11-2004)
| Kommentar Fra : Janf |
Dato : 17-11-04 21:51 |
|
Jacob Atzen wrote:
> Derudover synes jeg, det er en rigtig dårlig ide, at reducere
> læsbarheden for at lette tastearbejdet,
Enig.
> og tricks du laver her reducerer
> læsbarheden markant.
Ikke enig. Jeg mener faktisk at den øger læsbarheden.
På én måde forringes læsbarheden, fordi det er sværere at følge
værditildelingen til de anvendte variable. Derfor er din indvending både
forståelig og fornuftig.
På en anden måde forbedres læsbarheden fordi der simpelt hen ikke er så
meget rodet kode, der gør unyttigt arbejde, så som at flytte rundt på
data mellem forskellige midlertidige variable. Det er derfor jeg går ind
for den. Funktionen er simpelthen et skridt henimod at gøre PHP til et
højniveau sprog.
Men meget af alt dette er jo en smagssag og dermed med et potentiale til
at blive et religiøst spørgsmål.
--
Jan Fjeldmark mailto:janf@janf.dk http://janf.dk/
Hvad du end tror du er, så er du altid meget mere.
| |
|
|