[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

BRL vs PHP comparisons - reply to all Bruce's msgs.

Bruce Lewis wrote:
> To get form inputs in a way that works under prior releases as well
> as the default configuration for the latest PHP release, 4.1.0:
>   name=$HTTP_POST_VARS["name"];
>   age=$HTTP_POST_VARS["age"];
> Here's the BRL equivalent:
>  (inputs name age)

I don't see the relevance of using prior releases.  When people
mention Perl do they want comparisons to Perl 4?

Current PHP... no need to explicitly get inputs.

> (2) Embed them in text to be output.
>     This is cut/paste straight from http://www.php.net/tut.php
> Hi <?php echo $name; ?>.
> You are <?php echo $age; ?> years old.
> Here's the BRL equivalent:
> Hi [name].
> You are [age] years old.

Here's alternative PHP:
Hi <?= $name ?>
You are <?= $age ?> years old

or, another (admittedly ugly... but useful for bigger things
as you'll see...):

echo <<<EOF
Hi $name
You are $age years old.

> (4) Put it all together:
> ================= action.php ===================
> <?php
>   name=$HTTP_POST_VARS["name"];
>   age=$HTTP_POST_VARS["age"];
> ?>
> Hi <?php echo $name; ?>.
> You are <?php echo $age; ?> years old.
> <?php
> mail("nobody@example.com","$name is $age",
> "You just got a form filled in by somebody
> claiming to be $name (age $age).");
> ?>

Could become:

echo <<<EOF
Hi $name.
You are $age years old.

mail("nobody@example.com", "$name is $age",
"You just got a form filled in by somebody
claming to be $name (age $age).");

> Someone will want to claim that this example is too simple; that BRL
> will get more confusing than PHP as you add more examples.  The
> opposite is true, and newbies posting on the alt.php newsgroup give
> continual testimony to this fact.

I won't claim that the example in general is too short... however.

> What if they want a literal double quote in the body of the e-mail?
> PHP requires backslashing.  BRL does not.  Typical alt.php question.

No, but you require [ doubling.  Backslashing is (IMO) very common to
programmers comming from other languages. However... it depends what
level of 'newbie' you're talking about.

To quickly insert another email:
Bruce Lewis wrote in "[alt.php] [newbie] error :-|":
> One example early on in the BRL manual is this:
> [(define myface ]
> <img src="/img/myface.jpg" alt="Bruce's face">
> [)]
> It would have saved this newbie some confusion.  However, I can see from
> his subject line that he likes to use lots of different punctuation
> marks, so it's probably best he stick with PHP.  :-)

Using heredoc syntax:
<img src="/img/myface.jpg" alt="Bruce's face">

For any decent sized email I'd always recommend heredocs - unless you
specifically don't want variable interpolation.

$email = "nobody@example.com";
$subject = "$name is $age";
You just got a form filled in by somebody claiming to be $name (age $age).
Blah blah blah
"Double Quotes" or Bruce's "["'s not a problem.

mail($email, $subject, $msg_text);

That's probably just personal preference.

> What if they want to use foo($age) instead of $age?  In sending output
> to the page, they simply change $age to foo($age).  In the body of the
> e-mail, they must change $age to ".foo($age).".  Typical alt.php
> question.

True, though there is another alternative PHP way of doing this.  Not
much point mentioning it though as it doesn't help the PHP case! ;-)
(ok, I'll mention it... use of "{$....}".)

> Note that I made it easy on PHP by choosing an example that didn't
> require ${name} and ${age}.  BRL has no analagous issue.

True.  If someone's personal style preference was to always use the
${name} syntax, then they would have no issue either - as there'd
be nothing to change - the interpolation boundary ends at '}' just
as BRL's ends at ']';

> Do the dollar signs, backslashes, commas and semicolons in PHP really
> help make things more readable?  I think not.  Do multiple meanings of
> parens and square brackets confuse things with BRL?  Not at all.  [
> always means end a literal string.  ] always means start one.  (
> always precedes a verb in this example.  (Think of "inputs" as short
> for "define-inputs").  ) always ends a sentence.

Not ALWAYS always though.  As the very first example shows here:

> If you expect dollar signs before variable names, commas between
> arguments, and semicolons at the end of statments, you might like
> PHP.  If you're coming in with no such expectations, you'll like BRL.

Fair summary.  I find $ signs to stand out more in text.  Perhaps that's
because I've become used to them and scan for them subconsciously.

in "error handling, BRL vs PHP" Bruce Lewis wrote:
> If this newbie had an analagous problem with mail in BRL, he would have
> gotten a meaningful error message by default.  There may be some global
> errno you can check if PHP mail() returns false, but I don't know what
> it is, and none of the examples I've seen so far check the return value.

That is more the fault of the PHP examples than the language itself.  I
don't know how/if BRL allows you to catch errors where they occur, but
regardless.... I think error message reporting when there is a documented
return value to check would be a bit OTT, and possibly annoying.  Of
course, good error messages help track down the problem, but I can't
comment on this more without knowing how good BRL's error messages are.
(e.g. in this specific case would BRL complain that there was no MTA
to contact, or that sendmail (specifically) wasn't running, or that it's
flags were wrong... or...?)

In ("everything is a string" newbie friendly?) Bruce Lewis wrote:
> Someone posted on alt.php wondering why there was a 0 at the beginning
> of an e-mail message sent via PHP.
I'll have to look at BRL (general mental note).  I think the problem
pointed to is a general problem with any language that auto-converts
strings to numbers and/or objects dependent on context.  For this
case I really don't understand why the reply wasn't:
$who = "From: $sender";

What's your position on whether "everything is a string" is newbie
friendly or not? (perhaps that should be obvious from your aims
with BRL...  I'm not sure I equate text output with treating
everything as a string though.)

Oh, and another question.  Did you come up with the name BRL before
or after the pharse "Beautiful Report Language"?

When all's said and done, I'll be making sure I spend some time
playing with BRL as it does hold interest for me personally.  I'm
curious to see how long it'll be before I get over my aesthetic
disgust at:

Though... that's truthfully no worse than any other server-side
scripting languages, it doesn't seem to have the visual impact to
register on my programming radar.  No doubt I'll soon get used to it though.