Re: [PHP-DOC] cvs: phpdoc /en/functions mysql.xml

2002-04-10 Thread Hartmut Holzgraefe

Sander Roobol wrote:
 sanderWed Apr 10 11:24:56 2002 EDT
 
   Modified files:  
 /phpdoc/en/functions  mysql.xml 
   Log:
   Added note that mysql_real_esacpe_string() is only available in 4.3.0
   

version information has been updated today, so this is redundant ...

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de/  +49-711-99091-77




Re: [PHP-DOC] cvs: phpdoc /en/functions mysql.xml

2002-03-23 Thread Zak Greant

On March 22, 2002 00:27, Andrew Lindeman wrote:
 What do we do?

 On Thursday 21 March 2002 12:33 pm, Gabor Hojtsy wrote:
cnewbill Wed Mar 20 17:21:29 2002 EDT
   
  Modified files:
/phpdoc/en/functions mysql.xml
  Log:
  See Bug #16187 The second parameter can't be used cause a number
 
  cannot
 
be used as an object property.  ie row-0 is invalid while row-field
 
  is,
 
so MYSQL_NUM and MYSQL_BOTH don't matter it should always be
 
  MYSQL_ASSOC.
 
   Hold On!!!  Look in the source!?  The second param exists!  That's why
   I asked which was wrong?!
 
  The other point is that number object properties could exist.
 
  var_dump((object) array(1, 2, 3, 4));
 
  hm...
 
  The same for
 
  var_dump((object) array(+=|__-=.:'[] = 4));

  But this is valid (if somewhat nasty):

  $foo = 0;
  $obj-$foo = 10;
  echo $obj-$foo;

  --zak




Re: [PHP-DOC] cvs: phpdoc /en/functions mysql.xml

2002-03-21 Thread Gabor Hojtsy

  cnewbill Wed Mar 20 17:21:29 2002 EDT
 
Modified files:
  /phpdoc/en/functions mysql.xml
Log:
See Bug #16187 The second parameter can't be used cause a number
cannot
  be used as an object property.  ie row-0 is invalid while row-field
is,
  so MYSQL_NUM and MYSQL_BOTH don't matter it should always be
MYSQL_ASSOC.

 Hold On!!!  Look in the source!?  The second param exists!  That's why I
 asked which was wrong?!

The other point is that number object properties could exist.

var_dump((object) array(1, 2, 3, 4));

hm...

The same for

var_dump((object) array(+=|__-=.:'[] = 4));

Goba





Re: [PHP-DOC] cvs: phpdoc /en/functions mysql.xml

2002-03-21 Thread Andrew Lindeman

What do we do?

On Thursday 21 March 2002 12:33 pm, Gabor Hojtsy wrote:
   cnewbill Wed Mar 20 17:21:29 2002 EDT
  
 Modified files:
   /phpdoc/en/functions mysql.xml
 Log:
 See Bug #16187 The second parameter can't be used cause a number

 cannot

   be used as an object property.  ie row-0 is invalid while row-field

 is,

   so MYSQL_NUM and MYSQL_BOTH don't matter it should always be

 MYSQL_ASSOC.

  Hold On!!!  Look in the source!?  The second param exists!  That's why I
  asked which was wrong?!

 The other point is that number object properties could exist.

 var_dump((object) array(1, 2, 3, 4));

 hm...

 The same for

 var_dump((object) array(+=|__-=.:'[] = 4));

 Goba

-- 
The speed with which components become obsolete is directly proportional to 
the price of the component. 
-- Murphy's Computer Laws n°9



Re: [PHP-DOC] cvs: phpdoc /en/functions mysql.xml

2002-03-20 Thread Andrew Lindeman

Hold On!!!  Look in the source!?  The second param exists!  That's why I 
asked which was wrong?!

--Andrew

On Wednesday 20 March 2002 04:21 pm, Chris Newbill wrote:
 cnewbill  Wed Mar 20 17:21:29 2002 EDT

   Modified files:
 /phpdoc/en/functions  mysql.xml
   Log:
   See Bug #16187 The second parameter can't be used cause a number cannot
 be used as an object property.  ie row-0 is invalid while row-field is,
 so MYSQL_NUM and MYSQL_BOTH don't matter it should always be MYSQL_ASSOC.


 Index: phpdoc/en/functions/mysql.xml
 diff -u phpdoc/en/functions/mysql.xml:1.92
 phpdoc/en/functions/mysql.xml:1.93 ---
 phpdoc/en/functions/mysql.xml:1.92Tue Mar 19 14:54:07 2002
 +++ phpdoc/en/functions/mysql.xml Wed Mar 20 17:21:29 2002
  -1,5 +1,5 
  ?xml version=1.0 encoding=iso-8859-1?
 -!-- $Revision: 1.92 $ --
 +!-- $Revision: 1.93 $ --
   reference id=ref.mysql
titleMySQL Functions/title
titleabbrevMySQL/titleabbrev
  -1134,9 +1134,6 
   methodsynopsis
typeobject/typemethodnamemysql_fetch_object/methodname
   
 methodparamtyperesource/typeparameterresult/parameter/methodpara
m -  methodparam choice=opttypeint/typeparameter
 -result_type
 -   /parameter/methodparam
   /methodsynopsis
  para
   Returns an object with properties that correspond to the fetched
  -1150,11 +1147,18 
   their offsets (numbers are illegal property names).
  /para
  para
 - The optional argument parameterresult_type/parameter is a
 - constant and can take the following values: MYSQL_ASSOC,
 - MYSQL_NUM, and MYSQL_BOTH. See
 - functionmysql_fetch_array/function for explanation
 - of these constants.
 +  programlisting role=php
 +![CDATA[
 +?php
 +
 +// this is valid
 +echo $row-field;
 +// this is invalid
 +echo $row-0;
 +
 +?
 +]]
 +  /programlisting
  /para
  para
   Speed-wise, the function is identical to

-- 
Thus spake the master programmer:
When a program is being tested, it is too late to make design changes.
-- Geoffrey James, The Tao of Programming



Re: [PHP-DOC] cvs: phpdoc /en/functions mysql.xml

2001-12-10 Thread Friedhelm Betz


Hi Egon,

   Modified files:
 /phpdoc/en/functions mysql.xml
   Log:
   adding some php.ini related stuff in partintro.
   cleaning up the examples. some ws fixes.

 It wasn´t necessary reformatting the documentation. Please stop such
 commits. There is nothing wrong writing protos like:

 function_name (arguments)

 instead of

 function_name(arguments)

 I prefer the first.

 -Egon

This was not my idea. See the mail from Goba 4.12
Re: [PHP-DOC] persistent connections/mysql:

 I think we should not put a space after the function name
 and before the ( char. See the PEAR standards about this
 thing. That space is used with control structures and
 functions called without parenthesis (echo, print, include...).
 This is not a major issue. 

There was no reaction from anyone to this statement -;)
Therefore I thought this way of writing the protos is ok.
One says care for the pear standards, others say do not.
So how should this be done in the future?

 Friedhelm