Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:11084
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <40F0F8C2.4010300@actcom.net.il>
Date: Sun, 11 Jul 2004 11:22:26 +0300
User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040710)
MIME-Version: 1.0
To: Marc Richards <contact_marcos@yahoo.es>
CC: internals@lists.php.net
References: <20040708002654.7442.qmail@pb1.pair.com> <20040711024958.14248.qmail@pb1.pair.com>
In-Reply-To: <20040711024958.14248.qmail@pb1.pair.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New construct discussion Summary  
From: ilya79@actcom.net.il (Ilya Sher)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marc Richards wrote:
| Ok, so let me try to do a little summary.
|
|
| If and When
| -----------
| 1) There seems to be a general consensus that this feature should be
| implemented in SOME way.
| 2) It was too late for 5.0.0 so it will be targeted for 5.1
|
|
| What
| ----
| The requirements seem be:
| a) return the first variable/expression that isset()
| b) no error shouldbe thrown for unset variables
| c) short circuit evaluation
|
|
|
|
| How
| ---
| 1) ?: has been rejected for the following reasons.
|     - Possible confusion with the ternary operator
|     - Asymmetry with the ternary operator - since it tests isset()
|     - It is non-obvious in its functionality in and of itself
|     - It would be difficult to find info on it in the Docs
|     - There is no WIDESPREAD use in other languages (though it is
used
| in GCC) and PHP has been very strict about not introducing new
operators
| that are not already widely used (only 2 in 10 years)
|
|
| 2) Jason Garber suggested the following syntax: $a = $b setor $c;
$a = $b setor $c setor $d setor $e ... ?
too verbose IMHO
|
| While I like the fact that it is an operator instead of function, and
| therefore eases the process of chaining multiple operations
together, I
| see a problem.  Most PHP operators use non-alphanumeric characters,
| therefore making it easier to quickly see the difference between
| variable names and operators.  I believe the primary exceptions are
| "or", "and", and "xor".  These were most likely added because of a
| similarity with perl and can kinda get away with it since they are so
| short. "setor" just doesn't look like an operator to me.
|
|
| 3) So this leaves a function call which begs two questions: What
do we
| call it, and what is the function syntax.
|
| (a) What do we call it
|
| Various suggestions have been rejected because of similarity to
existing
| keywords.  These include: ifset(), ifelse(), ifexists() and
probably a
| few more.
|
| We can't extend isset() perform this functionality because isset()
| already takes multiple parameters.
|
| nvl(), ifnull() and coalesce() have been proposed because of similar
| existing functions in Oracle, MySQL and Postgres.  However Marcus has
| pointed out that these function test for null while we are testing
for
| existence.  I also think that since these functions are 1) not WIDELY
| used and 2) not terribly intuitively named (with the possible
exception
| of coalesce) we should probably not use them unless we are unable to
| come up with something else.
|
| This currently leaves us with a hand full of names, including:
| ifsetor(), firstset(), getval()/getvalue()/get_value() (Is there a
rule
| about underscores in new function names?).
firstset() is most logical name (at least for me)
|
|
| (b) What is the function syntax?
|
| Marcus has already looked into the issue and already created a patch,
| the existing patch only takes one variable and an optional default
| value (any expression).
|
| "ifsetor" "(" <variable> [ "," <expression> ] ")"
|
| According to Marcus:
|
| "Changing it to accept a list of *variables* could probably be
possible
| but would require heavy restructuring of the compiler. The same is
true
| for chaining it to accept a variable plus a list of expressions is
even
| more complicated."
Seems like excepting multiple variables is worth the effort:
	firstset($_GET['x'],$_POST['x'],'')
|
| Christian seem to be intent on trying to make it work, preferably
with
| the following format:
|
| "coalesce" "(" <expr> ( "," <expr> )* ")"
|
| Andi thinks we should "make a decision what the best way to go is and
| then we can discuss implementation if/what is possible".  They
will both
| probably not have time to look at this until after 5.0 is out.
|
|
| My current preference is
|
| "getval" "(" <expr> ( "," <expr> )* ")"
"firstset" "(" <expr> ( "," <expr> )* ")"
|
|
|
| Marc
|
|
|
|
|
| Marc Richards wrote:
|
|>
|> On 4/15/2004 Jason Garber asked about a new language construct to
|> simplify testing if a variable isset() and assinging a default value
|> for those that aren't.  The thread title was "Construct Request".
|>
|>
|> I rember reading it while the discussion went on, I just went
back and
|> browsed through it again.  Everyone seemed to agree the it was
|> generally a good idea and there was some minimal amount of consensus
|> on the ?: syntax, but I can't tell if this was ever implemented.
|>
|> Was it?  If not did I miss the reason why?
|>
|>
|> Marc
|
|


- --
PGP k: 3A4A 810C 1C81 79F3 A8C6  2545 90FD 6114 F730 0680
Rules: *NIX,UTF-8,Lisp,S-exps,FP,Encryption,OSS,VIM,Gnome
Sucks: M$,XML,Bad Code,Morons on the Web,toy text editors
Social Engineering - Because theres no patch for human stupidity.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA8PjBkP1hFPcwBoARAjfBAJ9FDYZQ6NJEGNLPLtIa4xWWWJzn9gCfa0eg
l63mGYP5oa8RsXrTXETBu7s=
=ktHL
-----END PGP SIGNATURE-----