Re: [PHP-DEV] New construct discussion Summary
-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" "(" [ "," ] ")"
|
| 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" "(" ( "," )* ")"
|
| 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" "(" ( "," )* ")"
"firstset" "(" ( "," )* ")"
|
|
|
| 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-
--
PHP Internals
Re: [PHP-DEV] PHP 5.0 crash on long php script with over 1000 lines
Gunnar, Did you try the latest CVS after Wez wrote his reply? Zeev At 16:52 10/07/2004, Gunnar von Boehn wrote: Hi, Please file a bugreport. Good idea :) I just wrote a bugreport. If anyone has an idea why PHP crashes so early on MorphOS and how this could be fixed , then i'll be very thankful. Cheers Gunnar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0 crash on long php script with over 1000 lines
Hi Zeev, No, I did not try the latest CVS yet. Actually I'm using a MorphOS PHP build which was made by a friend of mine. As you point out that the current CVS might fix this problem, we will try it out on MorphOS. I'll report back to you. (Hopefully success :-) ) Kind regards Gunnar On Jul 11, 2004, at 10:32 AM, Zeev Suraski wrote: Gunnar, Did you try the latest CVS after Wez wrote his reply? Zeev At 16:52 10/07/2004, Gunnar von Boehn wrote: Hi, Please file a bugreport. Good idea :) I just wrote a bugreport. If anyone has an idea why PHP crashes so early on MorphOS and how this could be fixed , then i'll be very thankful. Cheers Gunnar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary
--- Marc Richards <[EMAIL PROTECTED]> wrote: > 3) So this leaves a function call which begs two questions: > What do we call it, [snip] > These include: ifset(), ifelse(), ifexists() and [snip] > nvl(), ifnull() and coalesce() have been proposed because of > 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?). I addition to these, and Guy N. Hurst's excellent suggestions, I thought I'd throw a few into the mix, just for the sake of ideas. fix() safe_init() discern() concretize() One wag here also suggested: php_variable_quantum_waveform_collapse() but the least said about that, the better ... Out of the above, I think fix() and safe_init() are the better ones, although they possibly run the risk of causing conflicts with existing code, and being initially misleading with regards to their purpose. If semantic clarity is the primary criterion, I don't think we'll do much better than ifsetor(). Semantically, though, fix() works in both senses and, importantly, is nice and short. regards, Cris ___ALL-NEW Yahoo! Messenger - so many all-new ways to express yourself http://uk.messenger.yahoo.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
Hello Marc,
Sunday, July 11, 2004, 4:49:57 AM, you 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;
> 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?).
> (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" "(" [ "," ] ")"
> 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."
> Christian seem to be intent on trying to make it work, preferably with
> the following format:
> "coalesce" "(" ( "," )* ")"
> 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" "(" ( "," )* ")"
Marc, excellent work.
While reading this again i only missed the obvious ability to nest
ifsetor() calls (your own idea btw) to emulate coalesce. Anyway it may
be the best idea to simply apply the patch for ifsetor and find a way
to implement coalesce with exactly that name. I also think this is the
way to go if enough people want coalesce because in the majority of time
the situation that led to ifsetor doesn't require nor even has a need
for coalesce. To me it seems the call for coalesce only occured because
some people knew it from SQL and thought it could be more powerfull.
BUT remember that situation. It is the need to write E_NOTICE free
code and hence dealing with probably unset array indices or other
uninitialized data most probably from some form input. There you
currently need to do:
$a = isset($_GET['index']) ? $_GET['index'] : $default;
and this we want to change to:
$a = ifsetor($_GET['index'], $default);
and there is no need for coalesce. Coalesce comes into play when it
gets more complicated like when you implement fall backs. And also
the fallbacks are uninitialized. And again a but. But typically the
fallbacks come from ini or whatever files or databases. For all these
origins of data the values are define. If no we come to Marc's idea
of nesting:
$a = ifsetof($a, ifsetor($fallback, $default));
If it turns out that a majority
Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
On Sun, 11 Jul 2004, Marcus Boerger wrote: > $a = ifsetor($_GET['index'], $default); ifsetor() sounds a bit cumbersome to me. Some other suggestions: $a = is($_GET['index'], $default); $a = isor($_GET['index'], $default); $a = valid($_GET['index'], $default); $a = value($_GET['index'], $default); -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary
Ilya Sher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 firstset() is most logical name (at least for me) | The problem with firstset() is that it doesn't make as much sense if we are only testing one variable...but that is still to be determined. Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary
Not meaning to add more confusion, but Coldfusion (yes yes, please keep laughter to a minimum) has had a similar function since the beginning (IIRC). it's http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/tags-b13.htm Perhaps a php function "param(...)" ? Even though it's not always a request parameter we'll (developers) be checking, this will be true in most cases. S [the following heavily edited:] These include: ifset(), ifelse(), ifexists() nvl(), ifnull() and coalesce() have been proposed because of This currently leaves us with a hand full of names, including: ifsetor(), firstset(), getval()/getvalue()/get_value() fix() safe_init() discern() concretize() php_variable_quantum_waveform_collapse() >$a = is($_GET['index'], $default); >$a = isor($_GET['index'], $default); >$a = valid($_GET['index'], $default); >$a = value($_GET['index'], $default); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug in preg_match() ?
Hi,
This script:
outputs the following error:
Warning: Unknown modifier '/' in /home/michael/bug.php on
line 5
I thought it should find the match "m//" ...
Can you say, why search of the ending delimiter in a pattern cannot
be performed in a simple way, as you can see in the attached patch ?
Thanks.
--- ext/pcre/php_pcre.c.orig2004-07-11 19:10:25.0 +0300
+++ ext/pcre/php_pcre.c 2004-07-11 20:16:32.0 +0300
@@ -180,41 +180,17 @@
delimiter = pp[5];
end_delimiter = delimiter;
- if (start_delimiter == end_delimiter) {
- /* We need to iterate through the pattern, searching for the ending
delimiter,
- but skipping the backslashed delimiters. If the ending delimiter
is not
- found, display a warning. */
- pp = p;
- while (*pp != 0) {
- if (*pp == '\\' && pp[1] != 0) pp++;
- else if (*pp == delimiter)
- break;
- pp++;
- }
- if (*pp == 0) {
- php_error_docref(NULL TSRMLS_CC,E_WARNING, "No ending
delimiter '%c' found", delimiter);
- return NULL;
- }
- } else {
- /* We iterate through the pattern, searching for the matching ending
-* delimiter. For each matching starting delimiter, we increment
nesting
-* level, and decrement it for each matching ending delimiter. If we
-* reach the end of the pattern without matching, display a warning.
-*/
- int brackets = 1; /* brackets nesting level */
- pp = p;
- while (*pp != 0) {
- if (*pp == '\\' && pp[1] != 0) pp++;
- else if (*pp == end_delimiter && --brackets <= 0)
- break;
- else if (*pp == start_delimiter)
- brackets++;
- pp++;
- }
- if (*pp == 0) {
- php_error_docref(NULL TSRMLS_CC,E_WARNING, "No ending matching
delimiter '%c' found", end_delimiter);
- return NULL;
+ /* Search for the ending delimiter iterating from the end of the pattern */
+ pp = p + strlen(p) -1;
+ while (pp >= p) {
+ if(*pp == end_delimiter) {
+ break;
}
+ pp--;
+ }
+ if (pp < p) {
+ php_error_docref(NULL TSRMLS_CC,E_WARNING, "No ending delimiter '%c'
found", delimiter);
+ return NULL;
}
/* Make a copy of the actual pattern. */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
On Sun, 11 Jul 2004 09:43:51 -0700 (PDT), Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > On Sun, 11 Jul 2004, Marcus Boerger wrote: > > > $a = ifsetor($_GET['index'], $default); > > ifsetor() sounds a bit cumbersome to me. > > Some other suggestions: > > $a = is($_GET['index'], $default); > > $a = isor($_GET['index'], $default); > > $a = valid($_GET['index'], $default); I don't like valid, because that implies checks that aren't there (some sort of sanitizing). > > $a = value($_GET['index'], $default); > all of the other ones sound good - i like value() the best. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
* Thus wrote Rasmus Lerdorf: > On Sun, 11 Jul 2004, Marcus Boerger wrote: > > > $a = ifsetor($_GET['index'], $default); > > ifsetor() sounds a bit cumbersome to me. > > ... > > $a = value($_GET['index'], $default); I like value() although it might be a bit too generic, maybe add a word to it to help understand what the call does: $a = valueof($_GET['index'], $default); $a = valueor($_GET['index'], $default); Curt -- First, let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No, sir. Our model is the trapezoid! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary
Sean Coates wrote: Not meaning to add more confusion, but Coldfusion (yes yes, please keep laughter to a minimum) has had a similar function since the beginning (IIRC). it's http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/tags-b13.htm Perhaps a php function "param(...)" ? Even though it's not always a request parameter we'll (developers) be checking, this will be true in most cases. I don't think a function named param() really fits, but I do like the idea of adding a type check (or in the case of PHP a type cast) to the function. $level = (int) (isset($_SESSION['level']) ? $_SESSION['level'] : (isset($_REQUEST['level']) ? $_REQUEST['level'] : 1)) becomes $level = value($_SESSION['level'], $_REQUEST['level'], 1, INT); Of course, I have no idea how feasible this is. Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary
Marc Richards wrote: I don't think a function named param() really fits, but I do like the idea of adding a type check (or in the case of PHP a type cast) to the function. $level = (int) (isset($_SESSION['level']) ? $_SESSION['level'] : (isset($_REQUEST['level']) ? $_REQUEST['level'] : 1)) becomes $level = value($_SESSION['level'], $_REQUEST['level'], 1, INT); P.S. Aside from simply moving the type cast into the function, this would also avoid doing the cast on the default variable, which could be particularly useful if you want $level to be NULL...in which case it might be better to switch the order of the last two params since INT is "bound to" the variables, not the default $level = value($_SESSION['level'], $_REQUEST['level'], INT, 1); or $level = value($_SESSION['level'], $_REQUEST['level'], INT, NULL); or $level = value($_SESSION['level'], $_REQUEST['level'], INT); Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug in preg_match() ?
> Hi,
>
> This script:
>
> $line = "Use operator m// for matching strings";
> $pattern = "m//";
>
> if(preg_match("/$pattern/", $line, $match)) {
> print $match[0]."\n";
> }
> ?>
There is no bug here!
The final pattern is "/m///". When using // as delimeters, you must escape
them, so you would need to set
$pattern="m\/\/"
*or*
using other delimeter such as '~':
preg_match("~$pattern~",...)
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug in preg_match() ?
* Thus wrote Michael Spector:
>
> Hi,
>
> This script:
>
> $line = "Use operator m// for matching strings";
> $pattern = "m//";
>
> if(preg_match("/$pattern/", $line, $match)) {
> print $match[0]."\n";
> }
> ?>
>
> outputs the following error:
>
>
> Warning: Unknown modifier '/' in /home/michael/bug.php on
> line 5
>
>
> I thought it should find the match "m//" ...
>
> Can you say, why search of the ending delimiter in a pattern cannot
> be performed in a simple way, as you can see in the attached patch ?
Because of side effects like this:
$pattern = "Foo//i";
if(preg_match("/$pattern", $line, $match)) {
With your patch the preg_match has silently turned into a
caseINsensitve search.
Just use preg_quote($pattern, '/');
Curt
--
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about. No, sir. Our model is the trapezoid!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary
On Sun, 11 Jul 2004, Marc Richards wrote: > Marc Richards wrote: > > > I don't think a function named param() really fits, but I do like the > > idea of adding a type check (or in the case of PHP a type cast) to the > > function. > > > > > > $level = (int) (isset($_SESSION['level']) ? $_SESSION['level'] : > > (isset($_REQUEST['level']) ? $_REQUEST['level'] : 1)) > > > > becomes > > > > $level = value($_SESSION['level'], $_REQUEST['level'], 1, INT); > > > > P.S. Aside from simply moving the type cast into the function, this > would also avoid doing the cast on the default variable, which could be > particularly useful if you want $level to be NULL...in which case it > might be better to switch the order of the last two params since INT is > "bound to" the variables, not the default > > $level = value($_SESSION['level'], $_REQUEST['level'], INT, 1); > > or > > $level = value($_SESSION['level'], $_REQUEST['level'], INT, NULL); > > or > > $level = value($_SESSION['level'], $_REQUEST['level'], INT); This is starting to sound like the intval/floatval/strval functions that have been around for years and rarely used. We could simply soup these up a bit and thereby not add another function which could cause problems. Looks like it can be done without breaking backward compatibility too Of course, we would still need a version that didn't force the type, and in the case of the intval() function there is already a second optional arg whch specifies the base, so it isn't quite straightforward. So, perhaps introduce the value() function which doesn't do any type casting and enhance the intval(), strval() and floatval() functions to act like value() but cast appropriately unless the default arg is returned. To retain backward compatibility the intval() function's default arg would have to be after the optional base arg. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] New construct discussion Summary
Hello Marc, MR> I don't think a function named param() really fits, but I do like the MR> idea of adding a type check (or in the case of PHP a type cast) to the MR> function. MR> $level = (int) (isset($_SESSION['level']) ? $_SESSION['level'] : MR> (isset($_REQUEST['level']) ? $_REQUEST['level'] : 1)) MR> becomes MR> $level = value($_SESSION['level'], $_REQUEST['level'], 1, INT); MR> Of course, I have no idea how feasible this is. MR> Marc The concept is desirable, but can be achieved if you need it just as simply using already available syntax (ie a cast): $level = (integer) value($_SESSION['level'], 1); -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
Hello, RL> $a = value($_GET['index'], $default); value() sounds like more like a "language construct" to me. I'm not sure if it accurately conveys the meaning though (not that it has stopped other functions from being added in the past :) -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] New construct discussion Summary
On Sun, 11 Jul 2004, Jason Garber wrote: > The concept is desirable, but can be achieved if you need it just as > simply using already available syntax (ie a cast): > > $level = (integer) value($_SESSION['level'], 1); The problem with that is this: $level = (int) value($_SESSION['level'); Assume there is no level entry in the session array. This then effectively becomes: $level = (int) NULL; Guess what that gives you? Obviously not what we want here which is why we are talking about a mechanism to not cast that default value whether it be the unspecified NULL default, or whatever default is passed in. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
How about default($var, expr)? Andi At 09:43 AM 7/11/2004 -0700, Rasmus Lerdorf wrote: On Sun, 11 Jul 2004, Marcus Boerger wrote: > $a = ifsetor($_GET['index'], $default); ifsetor() sounds a bit cumbersome to me. Some other suggestions: $a = is($_GET['index'], $default); $a = isor($_GET['index'], $default); $a = valid($_GET['index'], $default); $a = value($_GET['index'], $default); -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Memory manager
When did you try that? Did you check with latest CVS because Wez made some
fixes.
At 09:37 PM 7/11/2004 +, Curt Zirzow wrote:
* Thus wrote Andi Gutmans:
> I think I'll roll on Monday. There's still a patch lingering.
> Does anyone else have something to commit?
>
This is completely broke:
file_get_contents('http://php.net/');
It returns partial content. See bug #29099
Curt
--
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about. No, sir. Our model is the trapezoid!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re[3]: [PHP-DEV] New construct discussion Summary
Sunday, July 11, 2004, 10:48:06 PM, you wrote:
RL> On Sun, 11 Jul 2004, Jason Garber wrote:
>> The concept is desirable, but can be achieved if you need it just as
>> simply using already available syntax (ie a cast):
>>
>> $level = (integer) value($_SESSION['level'], 1);
RL> The problem with that is this:
RL> $level = (int) value($_SESSION['level');
RL> Assume there is no level entry in the session array. This then
RL> effectively becomes:
RL> $level = (int) NULL;
RL> Guess what that gives you? Obviously not what we want here which is why
RL> we are talking about a mechanism to not cast that default value whether it
RL> be the unspecified NULL default, or whatever default is passed in.
What would be the point of casting something unless it was null? You
still have to do a type-check on the resultant value before you used
it for anything useful. It seems that in this case, reverting to the
ternary operator or the good old if() statement may be appropriate.
-- Before --
$level = value($_SESSION['level'], NULL, INT);
if(is_null($level)
{
//Initialize $level
}
-- After --
if(isset($_SESSION['level'])
{
$level = (integer) $_SESSION['level'];
}
else
{
//Initialize $level
}
I don't mean to be argumentative, but I'm just looking for a
application of what you said, as one is not coming to mind.
Thanks!
Jason
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
AG> How about default($var, expr)? I like it. -Jason -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
Andi Gutmans wrote: How about default($var, expr)? It might be a good idea to decide on a name for the construct before the PHP 5.0.0 release in order to make it a reserved word (marked for future use). -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] issue in copying the hash table(Reposted third time)
Hi Moriyoshi,
Fine.
Correcting myself.
Only once global_class_table is allocated and each thread just
increments the individual zend_class_entry while making a copy.
In linux I never faced the problem.
I can not say it as a problem with NetWare.
As per concept trying to copy sizeof(zend_class_entry) from some source
address where we are ensured of only sizeof(zend_class_entry*) bytes of
memory is illegal.
Even though the code works in Linux without any issues as of now. There
is a good chance of segfaulting in the future.
One more issue we allocate sizeof(zend_class_entry) where as we need
only sizeof(zend_class_entry*)(Wastage of 292-4=288 bytes).
Please correct me if I am wrong.
With regards
Kamesh Jayachandran
On Sat, 10 Jul 2004 22:59:32 +0900, "Moriyoshi Koizumi"
<[EMAIL PROTECTED]> said:
>
> On 2004/07/08, at 19:16, Kamesh Jayachandran wrote:
>
> > Hi Moriyoshi,
> > Sorry to copy the INIT_DATA macro in the mail.
> > #define INIT_DATA(ht, p, pData, nDataSize)
> > if (nDataSize == sizeof(void*)) {
> > memcpy(&(p)->pDataPtr, pData, sizeof(void *));
> > (p)->pData = &(p)->pDataPtr;
> > } else {
> >(p)->pData = (void *) pemalloc_rel(nDataSize,
> >(ht)->persistent);
> > if (!(p)->pData) {
> > pefree_rel(p, (ht)->persistent);
> > return FAILURE;
> > }
> >
> > memcpy((p)->pData, pData,
> > nDataSize);
> > (p)->pDataPtr=NULL;
> > }
> >
> > In case of deep copy the global_class_table,
> > For each class entry in the hash table, We call the above macro
> > INIT_DATA which allocates nDataSize( in this case 292) bytes for
> > zend_class_entry. We copy the corressponding entry(INIT_DATA).
>
> I don't know what you exactly mean by the word "deep copy",
> whether zend_hash_copy() duplicates the holding
> elements' instances themselves or not depends on the behaviour of the
> call
> back function passed to it. As for class entries, the call back just
> increases
> the reference counters and doesn't do the deep because the properties of
> entries will change in rare cases and it would be enough.
>
> > But the problem is in the NetWare port as I am not able copy the 292
> > bytes as the way with linux. The source address goes beyond my process
> > address space and I am getting segmentation fault.
>
> In this case each element is a pointer to a zend_class_entry
> instance which is allocated in a "persistent" manner and shared
> across threads, therefore those pointers should never be
> obfuscated like a variable in a stack frame at least.
>
> Thus that seems like a NetWare specific problem, otherwise some piece
> of code that is subtly violating a certain part of the address space
> destroys the hash table.
>
> > What is the likelyhood of having similar seg fault in Linux?
>
> I didn't experienced such a problem yet. Can I see the backtrace or
> something similar that helps to track down your problem?
>
> Moriyoshi
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] issue in copying the hash table(Reposted third time)
You seem to be right. I commited a patch. Please take a look and see if it
solves your problems.
At 11:02 PM 7/11/2004 -0700, Kamesh Jayachandran wrote:
Hi Moriyoshi,
Fine.
Correcting myself.
Only once global_class_table is allocated and each thread just
increments the individual zend_class_entry while making a copy.
In linux I never faced the problem.
I can not say it as a problem with NetWare.
As per concept trying to copy sizeof(zend_class_entry) from some source
address where we are ensured of only sizeof(zend_class_entry*) bytes of
memory is illegal.
Even though the code works in Linux without any issues as of now. There
is a good chance of segfaulting in the future.
One more issue we allocate sizeof(zend_class_entry) where as we need
only sizeof(zend_class_entry*)(Wastage of 292-4=288 bytes).
Please correct me if I am wrong.
With regards
Kamesh Jayachandran
On Sat, 10 Jul 2004 22:59:32 +0900, "Moriyoshi Koizumi"
<[EMAIL PROTECTED]> said:
>
> On 2004/07/08, at 19:16, Kamesh Jayachandran wrote:
>
> > Hi Moriyoshi,
> > Sorry to copy the INIT_DATA macro in the mail.
> > #define INIT_DATA(ht, p, pData, nDataSize)
> > if (nDataSize == sizeof(void*)) {
> > memcpy(&(p)->pDataPtr, pData, sizeof(void *));
> > (p)->pData = &(p)->pDataPtr;
> > } else {
> >(p)->pData = (void *) pemalloc_rel(nDataSize,
> >(ht)->persistent);
> > if (!(p)->pData) {
> > pefree_rel(p, (ht)->persistent);
> > return
FAILURE;
}
memcpy((p)->pData, pData,
> > nDataSize);
> > (p)->pDataPtr=NULL;
}
> >
> > In case of deep copy the global_class_table,
> > For each class entry in the hash table, We call the above macro
> > INIT_DATA which allocates nDataSize( in this case 292) bytes for
> > zend_class_entry. We copy the corressponding entry(INIT_DATA).
>
> I don't know what you exactly mean by the word "deep copy",
> whether zend_hash_copy() duplicates the holding
> elements' instances themselves or not depends on the behaviour of the
> call
> back function passed to it. As for class entries, the call back just
> increases
> the reference counters and doesn't do the deep because the properties of
> entries will change in rare cases and it would be enough.
>
> > But the problem is in the NetWare port as I am not able copy the 292
> > bytes as the way with linux. The source address goes beyond my process
> > address space and I am getting segmentation fault.
>
> In this case each element is a pointer to a zend_class_entry
> instance which is allocated in a "persistent" manner and shared
> across threads, therefore those pointers should never be
> obfuscated like a variable in a stack frame at least.
>
> Thus that seems like a NetWare specific problem, otherwise some piece
> of code that is subtly violating a certain part of the address space
> destroys the hash table.
>
> > What is the likelyhood of having similar seg fault in Linux?
>
> I didn't experienced such a problem yet. Can I see the backtrace or
> something similar that helps to track down your problem?
>
> Moriyoshi
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
