At 07:36 AM 4/15/2004 +0200, Thies C.Arntzen wrote:
Am 14.04.2004 um 21:53 schrieb Marcus Boerger:
Personally I'd much prefer a way of returning a value from a
constructor, i.e. to be able to 'return null;' or a similar language
construct so I could do 'if ($db = new SQLiteDatabase)'
It would
Hello Sterling,
Thursday, April 15, 2004, 7:55:17 AM, you wrote:
On Apr 14, 2004, at 10:36 PM, Thies C.Arntzen wrote:
if ctors are the only place that *cannot* life without exceptions it
would be well worth *fixing* (yes, i said fix), as adding
understanding exceptions to the list of
I don't like these ideas. I think it should stay the way it is and not only
because we're at RC2.
If Thies doesn't want to deal with this, then he can write constructors
without logic. It's not that hard for the one in many classes where this
might be needed.
Andi
At 08:20 AM 4/15/2004 +0200,
On Thu, 15 Apr 2004, Andi Gutmans wrote:
I don't like these ideas. I think it should stay the way it is and not only
because we're at RC2.
If Thies doesn't want to deal with this, then he can write constructors
without logic. It's not that hard for the one in many classes where this
might be
Hi,
I've got a situation where a seemingly innocent statement produces a
segfault. I've tried reducing it to a single reproducable testcase, but
without success. The problem is however solidly reproducable in the
context in which it occurs.
I'm *certain* it is caused by a mistake in *my* code,
Per Jessen wrote:
$editmain=strcasecmp($_REQUEST['contact'],main)==0;
//$editbilling=strcasecmp($_REQUEST['contact'],billing)==0;
//$edittechnical=strcasecmp($_REQUEST['contact'],technical)==0;
OK,
I've now guarded the above with :
if (
On Thu, 15 Apr 2004 12:44:20 +0200
Per Jessen [EMAIL PROTECTED] wrote:
Per Jessen wrote:
$editmain=strcasecmp($_REQUEST['contact'],main)==0;
//$editbilling=strcasecmp($_REQUEST['contact'],billing)==0;
[EMAIL PROTECTED] wrote:
First of all, PHP's object model is most similar to the Java one, so
Markus' comparisons make most sense in my eyes.
The object model might be similar to Java (it's a very simple one which
I like) but the language is not and *should not be* IMHO. Java got much
too
Andi Gutmans wrote:
I don't think allowing the return of anything except for the object
itself is *fixing* PHP.
No, being able to fail and return would not be fixing it. It would be
extending it to allow people to avoid exceptions for this simple case.
For example, in the SOAP extension it is
Derick Rethans wrote:
On Thu, 15 Apr 2004, Per Jessen wrote:
I'm *certain* it is caused by a mistake in *my* code, but I feel it isn't
exactly appropriate for php to segfault because of a user error?
Right, it's not supposed to do so. Please make a backtrace of the
segfault (with gdb),
[EMAIL PROTECTED] wrote:
First of all, PHP's object model is most similar to the Java one, so
Markus' comparisons make most sense in my eyes.
The object model might be similar to Java (it's a very simple one which
I like) but the language is not and *should not be* IMHO. Java got much
too
Hello,
I've followed the war, sorry, discussion about exceptions.
Now, let me introduce some problems I've found in Tidy.
Look at the code:
?
//doesn't echo any error, but should!
//should generate a E_WARNING because it can't find the file
$tidy = tidy_parse_string('sdgdsg',
Just to add some more thoughts to the ongoing discussion from a slightly
different POV.
The PEAR devs are trying to slowly prepare their packages for PHP5 and
so we also needed to address assignedments to $this in constructors in
the few packages that do so.
[EMAIL PROTECTED] wrote:
Actually those are a 'modern/dynamic' aspect of Java (being pseudo-closures).
And a very bad one indeed. Not everything modern is good.
dicuss on objective, rational arguments than on pure personal preference.
I gave more than enough rational arguments. If you don't
Lukas Smith wrote:
Our original idea was to handle this with an if statement like so:
if (version_compare(phpversion(), 5.0.0) == -1) {
// assign factoried method to this for PHP 4
// $this = Your_Package_Name::factory();
$this = Your_Package_Name::singleton();
} else {
// error
On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote:
No, I dislike them because they create more problems than they solve.
Then don't use them. You're a bit late to the party to debate their
existence in the language.
George
--
PHP Internals - PHP Runtime Development Mailing List
To
George Schlossnagle wrote:
Then don't use them. You're a bit late to the party to debate their
existence in the language.
I was late pointing out that copy-on-assignment is a mistake in PHP4, I
was late pointing out that there is no migration path for __clone(), I
was late with PPP and
Hi,
sorry but bugs.php.net seems unreachable.
Here is the reproductible problem I got, related to multiple queries in a
single sqlite_query call :
?PHP
$query = create table test1 (id integer primary key, name text);
create table test2 (id integer primary key, name text);
I noticed this problem the other day; it's related to the VM
query implementation in libsqlite.
--Wez.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 2:15 PM
Subject: [PHP-DEV] BugReport reproductible: sqlite and multiple queries
On Thu, 15 Apr 2004, George Schlossnagle wrote:
On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote:
No, I dislike them because they create more problems than they solve.
Then don't use them. You're a bit late to the party to debate their
But if some extension (e.g. sqlite) forces you
On Apr 15, 2004, at 9:49 AM, Jani Taskinen wrote:
On Thu, 15 Apr 2004, George Schlossnagle wrote:
On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote:
No, I dislike them because they create more problems than they solve.
Then don't use them. You're a bit late to the party to debate their
Hello Internals team,
Thank you for taking a moment to evaluate a serious request by a serious
php developer that is responsible for a development company of 15 employees.
In order to keep our code as clean and error free as possible, we opt to
develop in the E_ALL error mode, and
echo setor($required_variable, die('error...');
or
echo setor($error, '');
or
echo setor($sMessage, $sDefaultMessage).
or
$z = setor($_GET['z'], 'Default');
$z = setor($_GET['z'], 'Default');
Whats wrong with defining a user-level function?
function setor_array($array, $key, $default =
At 4/15/2004 11:28 AM -0400, Justin Hannus wrote:
echo setor($required_variable, die('error...');
or
echo setor($error, '');
or
echo setor($sMessage, $sDefaultMessage).
or
$z = setor($_GET['z'], 'Default');
$z = setor($_GET['z'], 'Default');
Whats wrong with defining a user-level function?
Hello,
Thank you for your efforts for making PHP code error free and clean.
Your idea to use common setor(arg1, arg2) function will completely
resolve the problem of variable existing evaluating and further
defaulting. By call of setor function developers will not take care
about
On Thu, 15 Apr 2004, Jason Garber wrote:
a. the actual variable in question could not be passed
b. it incurs the overhead of calling a user-level function
Which takes about as much time as calling an internal function, so that
argument is bogus.
Derick
--
PHP Internals - PHP Runtime
I am not sure what would be the best name for such an engine construct or a
function, but the idea itself is good (IMHO). It would certainly make it
easier to write safer notice free code.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
That is basically the same idea once proposed as extending
the ternary operator (credit goes to GCC and its C extension).
$bar ? : $baz;
If $bar evaluates to true, the expression evaluates to $bar
or to 0, respectively.
- Sascha
--
PHP Internals - PHP Runtime
Lukas Smith wrote:
Our original idea was to handle this with an if statement like so:
if (version_compare(phpversion(), 5.0.0) == -1) {
// assign factoried method to this for PHP 4
// $this = Your_Package_Name::factory();
// $this = Your_Package_Name::singleton();
eval('$this =
Brad Fisher wrote:
Lukas Smith wrote:
Our original idea was to handle this with an if statement like so:
if (version_compare(phpversion(), 5.0.0) == -1) {
// assign factoried method to this for PHP 4
// $this = Your_Package_Name::factory();
// $this = Your_Package_Name::singleton();
On 15 Apr 2004 at 11:47, Jason Garber wrote:
a. the actual variable in question could not be passed
This is wrong, too. Look at this example:
?php
error_reporting(E_ALL | E_STRICT);
function param($param, $default, $type = null)
{
if (!isset($param)) {
$param = $default;
}
Actually, although suppressing the E_NOTICE, this is not exactly the
behavior you want.
What if $_GET['Does']['Not']['Exist'] really doesn't exists? It is then
created and assigned to $param when passed as an argument to the param
function. Therefore polluting $_GET with another unused array and
On Thu, 15 Apr 2004, Andi Gutmans wrote:
I held RC2 because I thought this was a critical engine bug. It happened
because instead of not implementing NULL you implemented it without a body.
Right now I changed it to NULL which means that any clone either via
clone or compatibility_mode will
Is there a good reason to NOT implement this?
If not, I'm +1 on that (if I carry ANY weight at all (-: )
BC isn't an issue, and it would be a very useful feature, IMHO..
S
Sascha Schumann wrote:
That is basically the same idea once proposed as extending
the ternary operator (credit goes
It could be implemented but I don't see the big advantage over $bar ? 0 : $base
It's one character...
At 02:09 PM 4/15/2004 -0400, Sean Coates wrote:
Is there a good reason to NOT implement this?
If not, I'm +1 on that (if I carry ANY weight at all (-: )
BC isn't an issue, and it would be a very
The best functionality would be for it to return the value, not re-assign
it. Many of the things being talked about would modify the sent parameter,
rather than return selected value.
For instance (using the isset_or_default()) call:
$nCustID = (int) isset_or_default($_POST['CUST_ID'], 0);
Sascha Schumann wrote:
That is basically the same idea once proposed as extending
the ternary operator (credit goes to GCC and its C extension).
$bar ? : $baz;
yes, that looks like the way it should look like,
and the danger of newbees abusing it would be way lower
than with a function
On Apr 15, 2004, at 3:35 PM, Timm Friebe wrote:
On Thu, 2004-04-15 at 21:36, Chuck Hagenbuch wrote:
Quoting Hartmut Holzgraefe [EMAIL PROTECTED]:
[...]
If this were added, wouldn't it make sense to use the convention
already adopted
by perl?
$foo |= 'default';
Already used:
$ php -r '$a= 1; $a
On Thu, 15 Apr 2004, Jason Garber wrote:
$_POST['CUST_ID'] = (int) isset_or_default($_POST['CUST_ID'], 0);
I agree that it would be helpful not to evaluate the second parameter
unless needed, which is why I originally proposed a language construct.
You'll need something more clever, because
Hi Derick,
I see. I was basing the spec on the functionality of isset() which does
not (obviously) throw an E_NOTICE when you pass an undefined variable to
it. However, do you see any reason that this would not reliably work?
function setor($param, $default)
{
return (isset($param) ?
On Thu, 15 Apr 2004, Jason Garber wrote:
I see. I was basing the spec on the functionality of isset() which does
not (obviously) throw an E_NOTICE when you pass an undefined variable to
it. However, do you see any reason that this would not reliably work?
I wrote this (I underlined the
I wrote this (I underlined the relevant parts for you):
You'll need something more clever, because
an undefined key 'CUST_ID' in $_POST['CUST_ID'] will strill throw a
Consider this:
---
?php
error_reporting(E_ALL);
function setor($param, $default)
{
You can avoid the E_NOTICE using a reference, but it can have undesired
side effects. For example, if you pass $x[5] by reference (whether to
an internal function or a user defined function), $x[5] will be
created and set to NULL. To avoid this side-effect, don't use the
reference and instead
+1 for the GCC style syntax.
--Wez.
- Original Message -
From: Hartmut Holzgraefe [EMAIL PROTECTED]
To: Sascha Schumann [EMAIL PROTECTED]
Cc: Ilia Alshanetsky [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 8:47 PM
Subject: Re: [PHP-DEV] Construct Request
Sascha
On Thu, 15 Apr 2004, George Schlossnagle wrote:
On Apr 15, 2004, at 9:49 AM, Jani Taskinen wrote:
On Thu, 15 Apr 2004, George Schlossnagle wrote:
On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote:
No, I dislike them because they create more problems than they solve.
Then don't use
On Thu, 15 Apr 2004, Andi Gutmans wrote:
Guys, I'm am not for forcing people to use exceptions.
Marcus is.. :)
I agree that we should make PHP another Java exceptions from hell
(especially with their exception declarations in function prototypes which
is horrible). I'm just
I
Hello Jani,
Thursday, April 15, 2004, 10:49:17 PM, you wrote:
On Thu, 15 Apr 2004, Andi Gutmans wrote:
Guys, I'm am not for forcing people to use exceptions.
Marcus is.. :)
I don't. If you don't like the oo interface of SQLite then go with the
procedural API. For the way i implemented
Hello Derick,
Thursday, April 15, 2004, 9:59:23 AM, you wrote:
On Thu, 15 Apr 2004, Andi Gutmans wrote:
I don't like these ideas. I think it should stay the way it is and not only
because we're at RC2.
If Thies doesn't want to deal with this, then he can write constructors
without logic.
Hello Christian,
Thursday, April 15, 2004, 1:15:03 PM, you wrote:
Andi Gutmans wrote:
I don't think allowing the return of anything except for the object
itself is *fixing* PHP.
No, being able to fail and return would not be fixing it. It would be
extending it to allow people to avoid
On Thu, 15 Apr 2004, Marcus Boerger wrote:
I don't. If you don't like the oo interface of SQLite then go with the
procedural API. For the way i implemented SQLite's oo API exceptions are the
way to go - a gingle exception in the ctor.
There is nothing wrong with that at all, it's just the
Hello Derick,
Thursday, April 15, 2004, 11:02:14 PM, you wrote:
On Thu, 15 Apr 2004, Marcus Boerger wrote:
I don't. If you don't like the oo interface of SQLite then go with the
procedural API. For the way i implemented SQLite's oo API exceptions are the
way to go - a gingle exception in
Hello Christian,
Thursday, April 15, 2004, 1:06:20 PM, you wrote:
[EMAIL PROTECTED] wrote:
modern dynamic languages in that context, as for instance in Python
there is no error handling but by using exceptions).
Sorry but that's simply wrong. Python methods can return false or null
as
Hello Derick,
Thursday, April 15, 2004, 10:07:01 PM, you wrote:
On Thu, 15 Apr 2004, Jason Garber wrote:
I see. I was basing the spec on the functionality of isset() which does
not (obviously) throw an E_NOTICE when you pass an undefined variable to
it. However, do you see any reason that
Hello Justin,
Thursday, April 15, 2004, 5:28:29 PM, you wrote:
echo setor($required_variable, die('error...');
or
echo setor($error, '');
or
echo setor($sMessage, $sDefaultMessage).
or
$z = setor($_GET['z'], 'Default');
$z = setor($_GET['z'], 'Default');
Whats wrong with defining a
On Apr 15, 2004, at 5:21 PM, Marcus Boerger wrote:
Hello Christian,
Thursday, April 15, 2004, 1:06:20 PM, you wrote:
[EMAIL PROTECTED] wrote:
modern dynamic languages in that context, as for instance in Python
there is no error handling but by using exceptions).
Sorry but that's simply wrong.
Hello folks,
In all functions using spprintf(), the output corresponding to the
format conversion specifier %p depends on the value of the
*previously* converted argument (if any), not just the pointer
corresponding to the specifier.
1) If the previously-converted argument was a non-zero integer,
Jason Garber wrote:
function setor($param, $default)
{
return (isset($param) ? $param : $default);
}
I tested it on 4.3.4 and 5.0 RC1, and it worked. Is passing an
undefined variable as a reference parameter a legal thing to do in PHP?
That bring up an interesting point:
Sean Coates wrote:
Jason Garber wrote:
function setor($param, $default)
{
return (isset($param) ? $param : $default);
}
I tested it on 4.3.4 and 5.0 RC1, and it worked. Is passing an
undefined variable as a reference parameter a legal thing to do in PHP?
That bring up an interesting
At 02:21 PM 4/15/2004 -0400, Sean Coates wrote:
Andi Gutmans wrote:
It could be implemented but I don't see the big advantage over $bar ? 0 :
$base
It's one character...
oes to GCC and its C extension).
$bar ? : $baz;
If $bar evaluates to true, the expression evaluates to $bar
or to
Guys, I'm am not for forcing people to use exceptions. I agree that we
should make PHP another Java exceptions from hell (especially with their
exception declarations in function prototypes which is horrible). I'm just
saying, that some extensions might benefit from exceptions and the
Hello,
Let me make an attempt to clarify what I originally requested.
--
A function/construct named setor() modeled after isset(), which takes 2
parameters:
parameter 1, the variable in question
parameter 2, the default value
if(isset($parameter1))
return $parameter1;
else
return
Attached is a patch which I hope will keep people happy when it comes to
specifically the Tidy extension. I'd like some feedback on this before I
commit it / throw it away:
Changes:
- All errors were re-evaluated, and those (such as a bogus config
option) were demoted to E_NOTICE or
Hello Eric,
thanks for noticing.
marcus
Thursday, April 15, 2004, 11:30:07 PM, you wrote:
Hello folks,
In all functions using spprintf(), the output corresponding to the
format conversion specifier %p depends on the value of the
*previously* converted argument (if any), not just the
Hello Jevon,
Friday, April 16, 2004, 1:05:11 AM, you wrote:
Guys, I'm am not for forcing people to use exceptions. I agree that we
should make PHP another Java exceptions from hell (especially with their
exception declarations in function prototypes which is horrible). I'm just
saying, that
64 matches
Mail list logo
