Req #41856 [Com]: support for anonymous classes

[krak...@php.net]

Edit report at https://bugs.php.net/bug.php?id=41856&edit=1

 ID: 41856
 Comment by: krak...@php.net
 Reported by:mbaynton at gmail dot com
 Summary:support for anonymous classes
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:5.2.3
 Block user comment: N
 Private report: N

 New Comment:

http://wiki.php.net/rfc/anonymous_classes


Previous Comments:

[2013-09-02 22:06:30] johan...@php.net

My guess is that anonymous classes would have a good chance once a good 
implementation comes by. This is not completely trivial as the class_entry has 
to be stored in the class_table but has to be somewhat hidden and we might have 
to find a way to hide the information in the oparray.

As all things in PHP this needs a volunteer to do it. All contributors have 
sometime X to work on PHP and in time X can either discuss stuff, fix bugs or 
implement features ... but with some guidance this might be a nice project for 
a newcomer (I'd volunteer to give a hand to point in the right direction etc., 
while  this guarantees acceptance in no way as that would need an RFC etc.) 
until then we have to live with workarounds.

For the PageController interface example an (work-around) alternative is

$page_controller = [
  'get'  => function () {},
  'post' => function () {}
};


[2013-09-02 21:42:36] zatacorothx at gmail dot com

Anonymous classes in Java are convenient when used with Interfaces. In PHP, 
this 
could help with MVC frameworks. Say all pages had a class that implemented 
PageController:
[some_page.php]
$page_controller = new PageInterface() {
  function doGet() {}
  function doPost() {}
};

A current workaround would be using a factory or constructor to which you pass 
required methods, and not using an interface. It works, but then you have to 
deal with missing methods in application logic where you could otherwise just 
handle an error.


[2013-07-22 15:32:27] pacerier at gmail dot com

+1


[2012-03-15 18:45:47] paj...@php.net

Not exactly the same but look at closure and traits support in 5.4.


[2012-03-15 18:35:55] david71rj at gmail dot com

+1




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=41856


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=41856&edit=1

Bug #43721 [Com]: parse_url does not handle "protocol relative" URLs

[yastrakhan at wikimedia dot org]

Edit report at https://bugs.php.net/bug.php?id=43721&edit=1

 ID: 43721
 Comment by: yastrakhan at wikimedia dot org
 Reported by:phpbugs at thequod dot de
 Summary:parse_url does not handle "protocol relative" URLs
 Status: Not a bug
 Type:   Bug
 Package:URL related
 Operating System:   Ubuntu Linux
 PHP Version:5.2.5
 Block user comment: N
 Private report: N

 New Comment:

I also think this is a very unintuitive behavior - protocol-relative URLs are 
very common, while the file:// has very limited and archaic use. parse_url() 
should behave very similar to modern browsers.


Previous Comments:

[2013-01-24 09:13:31] victor dot sollerhed at gmail dot com

I think this actually is a bug. Could this please be re-opened?

"A relative URL without a scheme (http: or https:) is valid, per RFC 3986: 
"Uniform Resource Identifier (URI): Generic Syntax", Section 4.2. If a client 
chokes on it, then it's the client's fault because they're not 
complying with the URI syntax specified in the RFC."

Please see:

http://stackoverflow.com/questions/550038/is-it-valid-to-replace-http-with-in-a-
script-src-http

http://stackoverflow.com/questions/3583103/network-path-reference-uri-scheme-
relative-urls/


[2007-12-31 21:27:22] il...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

That's expected, because unless a protocol is specified, it assumes 
file://


[2007-12-31 18:10:32] phpbugs at thequod dot de

Description:

parse_url does not parse "protocol relative" URLs correctly.

"protocol relative" URLs start with to slashes, leaving the "proto:" 
part out.

parse_url should parse them like a "http://"; url, but leave 
the "protocol" key unset, as far as I can see.

See RFC3986.

Reproduce code:
---
$ php -r '$p = parse_url("//example.com/bar"); var_dump($p);'


Expected result:

array(2) {
  ["host"]=>
  string(11) "example.com"
  ["path"]=>
  string(17) "/bar"
}


Actual result:
--
array(1) {
  ["path"]=>
  string(17) "//example.com/bar"
}







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=43721&edit=1

Req #36943 [Com]: SCGI support

[a at b dot com]

Edit report at https://bugs.php.net/bug.php?id=36943&edit=1

 ID: 36943
 Comment by: a at b dot com
 Reported by:webstorm at netcourrier dot com
 Summary:SCGI support
 Status: Open
 Type:   Feature/Change Request
 Package:Other web server
 Operating System:   Windows
 PHP Version:5.1.2
 Block user comment: N
 Private report: N

 New Comment:

Fast-CGI ties up the CGI until the request is handled.  SCGI allows multiple 
requests to be concurrently handled by a single CGI.  This matters if handling 
one request has significant latency.

Apache 2.5 does not support fast-cgi out of the box and I think 
mod_proxy_fastcgi has fallen prey to bitrot; I could not make it compile.


Previous Comments:

[2010-03-15 18:17:27] paj...@php.net

> SCGI is supported by Apache, FastCGI is not.  Go ahead.

FastCGI is actually supported by apache and next versions should have it 
included.


[2010-03-15 18:14:38] peter_jones_jr at yahoo dot com

Please discuss this on the PHP mailing list before sending feature requests.

PHP should not support each and every protocol out there, especially if it has 
NO advantage over FastCGI. From the "spec":

"When the SCGI server sees the end of the request it sends back a response and 
closes the connection. The format of the response is not specified by this 
protocol."

This "protocol spec" doesn't make any sense to me. 

Note that there are several Java FastCGI servlets available, so there's no need 
to add more complexity to the PHP core.


[2007-09-23 08:43:11] js at iksz dot hu

SCGI is supported by Apache, FastCGI is not.  Go ahead.


[2006-04-02 14:04:44] webstorm at netcourrier dot com

I tried to use FastCGI but I have 2 problems :
  1) I didn't found the FastCGI binaries, do i need to recompile source (i'm 
using Windows) ?
  2) According to the FastCGI specification, when the FastCGI is started, the 
web server have to pass the handle (file number) of the opened socket to the 
FastCGI. How can this be done with Java ?


[2006-04-01 20:55:39] scottmacvicar at ntlworld dot com

It's just another FastCGI type protocol but far easier to implement, see 
http://python.ca/nas/scgi/protocol.txt for the spec.

Creating a SCGI API would be fairly straight forward.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=36943


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=36943&edit=1

Req #64242 [Asn]: Extend date() formats with week number of year, weeks starting on Sunday

[derick]

Edit report at https://bugs.php.net/bug.php?id=64242&edit=1

 ID: 64242
 Updated by: der...@php.net
 Reported by:thbley at gmail dot com
 Summary:Extend date() formats with week number of year,
 weeks starting on Sunday
 Status: Assigned
 Type:   Feature/Change Request
 Package:Date/time related
 Operating System:   ANY
 PHP Version:5.5.0alpha4
 Assigned To:kriscraig
 Block user comment: N
 Private report: N

 New Comment:

PHP implements the ISO 8601 calendar, where weeks start with Monday - this 
should not be implemented.


Previous Comments:

[2013-02-19 07:14:17] thbley at gmail dot com

Description:

Extend date() formats like
  W ISO-8601 week number of year, weeks starting on Monday
with
  V week number of year, weeks starting on Sunday

Example:
date("W V", strtotime("2012-12-30")); // 52 53
date("W V", strtotime("2012-12-31")); // 01 53

E.g. MySQL has date_format() formats:
  %VWeek (01..53), where Sunday is the first day of the week; used with %X
  %vWeek (01..53), where Monday is the first day of the week; used with %x







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64242&edit=1

Bug #64332 [Opn->Nab]: Problems with BR Save time (BRST)

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=64332&edit=1

 ID: 64332
 Updated by: ahar...@php.net
 Reported by:bernardo at datamex dot com dot br
 Summary:Problems with BR Save time (BRST)
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Date/time related
 Operating System:   Window,Linux,FreeBSD
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

PHP uses the Olson time zone database. Older versions of PHP have older 
versions 
of the database bundled, and can be updated using the PECL timezonedb package.

It appears that the bundled time zone database is correct in newer versions of 
PHP: http://3v4l.org/a1i0h suggests that the relevant fixes went into PHP 
5.3.19, 
5.4.9 and 5.5.0.

Closing, since this is fixed in current versions.


Previous Comments:

[2013-09-19 01:57:49] bernardo at datamex dot com dot br

Please read this part "Does Brazil observe Daylight Saving Time?" in link 
http://wwp.greenwichmeantime.com/time-zone/south-america/brazil/time-brazil/

Brazil Decree No. 7826 of 15 October.2012.
Gives new wording of art. 2 of  Decree No. 6558 of 08 September 2008 
establishing daylight saving time in part of the national territory. Daylight 
saving time will be valid in the states of Rio Grande do Sul, Santa Catarina, 
Parana, Sao Paulo, Rio de Janeiro, Espirito Santo, Minas Gerais, Goiás, Mato 
Grosso, Mato Grosso do Sul, Tocatins and the Federal District.


[2013-09-18 22:37:13] cmbecker69 at gmx dot de

If I'm not mistaken the "actual results" are correct, and the 
"expected results" are wrong.  At least according to Wikipedia[1] 
America/Sao_Paulo and America/Bahia have the same offset to UTC
and identical DST offset.

If so, this is not a bug (but rather an older bug was fixed).

[1] 


[2013-03-01 17:59:17] bernardo at datamex dot com dot br

Description:

I changed my server application before Freebsd with php 5.3.3 now Ubuntu with 
php 
5.3.10.
I noticed that there are differences between treatment dates in different 
timezones.

Note that when BRST "America/Sao_Paulo" advances one hour.

Test script:
---


NOWIn BRST ({$time})


{$timezone}{$agoraAqui}{$antesAqui}


America/Bahia{$agoraLa}{$antesLa}



time-brazil
";
?>

Expected result:

NOW | In BRST (1358258400)
America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00


Actual result:
--
Correct in:
- freebsd + php 5.3.3
- freebsd + php 5.3.6
- windows + php 5.3.8

NOW | In BRST (1358258400)
America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00

Error in:
- freebsd + php 5.3.10
- ubuntu + php 5.3.10
- windows + php 5.4.3

NOW | In BRST (1358258400)
America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 12:00:00







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64332&edit=1

Bug #65705 [Opn->Fbk]: simplexml_load_string does not honor error_reporting settting

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=65705&edit=1

 ID: 65705
 Updated by: ahar...@php.net
 Reported by:oskar dot mothander at gmail dot com
 Summary:simplexml_load_string does not honor error_reporting
 settting
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:SimpleXML related
 Operating System:   Windows 7 (64)
 PHP Version:5.4.19
 Block user comment: N
 Private report: N

 New Comment:

I can't reproduce this: setting display_errors to false or removing E_WARNING 
from error_reporting() quiets the warnings as expected for me.

Do you have any extensions loaded that may interfere with error reporting, such 
as xdebug or scream? (You can check this via phpinfo().) If not, does this 
still 
occur on a current version of PHP (ie 5.4.20 or 5.5.4)?


Previous Comments:

[2013-09-19 08:34:46] oskar dot mothander at gmail dot com

Description:

Calling simplexml_load_string() on invalid xml will output Warnings even though 
you've been a good developer and turned these OFF on live environment.

Using "libxml_use_internal_errors(true);" fixes the problem but shouldn't be 
nessesary. 

This caused my site to display Warnings live.

Affected versions: 
PHP 5.4.3 (not in the list above?)
PHP 5.3.8 (VC9 X86 32bit thread safe) + PEAR


Test script:
---
ini_set("display_errors", false);
simplexml_load_string('');
// Will still output Warnings even though they are off.

Expected result:

Empty result

Actual result:
--
Warning: simplexml_load_string() [function.simplexml-load-string]: Entity: line 
1: 
parser error : Premature end of data in tag apa line 1 on line 2

Warning: simplexml_load_string() [function.simplexml-load-string]:  on 
line 2

Warning: simplexml_load_string() [function.simplexml-load-string]: ^ on line 2






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65705&edit=1

Bug #65708 [Opn->Csd]: dba functions cast $key param to string in-place, bypassing copy on write

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=65708&edit=1

 ID: 65708
 Updated by: ahar...@php.net
 Reported by:gary_whittles at hotmail dot com
 Summary:dba functions cast $key param to string in-place,
 bypassing copy on write
-Status: Open
+Status: Closed
 Type:   Bug
 Package:DBM/DBA related
 Operating System:   Fedora 17
 PHP Version:5.5Git-2013-09-19 (Git)
-Assigned To:
+Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Commit:
https://github.com/php/php-src/commit/30e0442c549bd20288ca8754daa0cdf24d98f055


Previous Comments:

[2013-09-19 10:23:55] gary_whittles at hotmail dot com

Description:

Calling dba functions (e.g. dba_exists/dba_insert) with a non-string key causes 
the key to be cast to a string.  This also affects any variables that are 
copies 
of the key variable.

This seems to be independent of database type - tested with db4 and flatfile 
databases.

Test script:
---
https://bugs.php.net/bug.php?id=65708&edit=1

[PHP-BUG] Bug #65738 [NEW]: Column metadata for datetimeoffset is incorrect

[chri...@php.net]

From: chriskl
Operating system: Debian 7.1
PHP version:  5.5.4
Package:  MSSQL related
Bug Type: Bug
Bug description:Column metadata for datetimeoffset is incorrect

Description:

When using getColumnMeta() on pdo_dblib, on a column of type 
'datetimeoffset(0)', the returned structure looks like this:

array(10) {
  ["max_length"] => int(104)
  ["precision"] => int(0)
  ["scale"] => int(0)
  ["column_source"] => string(7) "updated"
  ["native_type"] => string(4) "char"
  ["native_type_id"] => int(47)
  ["native_usertype_id"] => int(0)
  ["name"] => string(7) "updated"
  ["len"] => int(104)
  ["pdo_type"] => int(2)
}

Note that it believes that the native_type is char, when it should be 
'datetimeoffset'.

Expected result:

I expect to see 'datetimeoffset' as the native_type.

Actual result:
--
You get 'char' - which is incorrect.

-- 
Edit bug report at https://bugs.php.net/bug.php?id=65738&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65738&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65738&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65738&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65738&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65738&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65738&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65738&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65738&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65738&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65738&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65738&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65738&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65738&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65738&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65738&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65738&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65738&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65738&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65738&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65738&r=mysqlcfg

Bug #65738 [Com]: Column metadata for datetimeoffset is incorrect

[chri...@php.net]

Edit report at https://bugs.php.net/bug.php?id=65738&edit=1

 ID: 65738
 Comment by: chri...@php.net
 Reported by:chri...@php.net
 Summary:Column metadata for datetimeoffset is incorrect
 Status: Open
 Type:   Bug
 Package:MSSQL related
 Operating System:   Debian 7.1
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Actually, unfortunately on a real char field, it also returns "char" and also 
type 
47 :(  So I'm not sure how to distinguish these.


Previous Comments:

[2013-09-23 02:53:43] chri...@php.net

Description:

When using getColumnMeta() on pdo_dblib, on a column of type 
'datetimeoffset(0)', the returned structure looks like this:

array(10) {
  ["max_length"] => int(104)
  ["precision"] => int(0)
  ["scale"] => int(0)
  ["column_source"] => string(7) "updated"
  ["native_type"] => string(4) "char"
  ["native_type_id"] => int(47)
  ["native_usertype_id"] => int(0)
  ["name"] => string(7) "updated"
  ["len"] => int(104)
  ["pdo_type"] => int(2)
}

Note that it believes that the native_type is char, when it should be 
'datetimeoffset'.

Expected result:

I expect to see 'datetimeoffset' as the native_type.

Actual result:
--
You get 'char' - which is incorrect.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65738&edit=1