headers
sean finney | 4 Jul 09:51
Favicon

[PHP-DEV] are there alternate interfaces to the bug tracking system?

hi everyone,

(if there's a better place to ask this, my apologies and feel free to
 redirect me!)

does anyone know here if there is any machine-friendly interface to
the php bug tracking system?

in debian we have a service called "bts-link"[1] which we can use to track
"forwarded" bugs in remote systems's (i.e. a bug reported in debian which
has been linked with another bug such as one on bugs.php.net).  for
debian package maintainers this is a major boon since we can keep
better track of bugs that have been fixed or otherwise addressed
"upstream".

so what i'm wondering is: is there an easily parseable or structured
interface (xmlrpc, soap, read-only JSON export, whatever) to the php.net bts
that could be used to get a bug's information?  or would such a bts-link
service need to resort to scraping the page for a particular bug's status?

thanks!
	sean

[1] http://bts-link.alioth.debian.org/

ps - I'm cc'ing Sandro Tosi, who i believe could answer any questions
     you might have about the bts-link service in case you would only
     provide such access under certain conditions (he is not subscribed
     to this list).
(Continue reading)

Permalink | Reply | 5 comments |
headers
Lukas Kahwe Smith | 4 Jul 08:17

[PHP-DEV] weak and strict type checking RFC

Hi,

Last evening I put together a quick proposal for a weak and strict  
checking approach, since I felt that things were being concluded a bit  
prematurely. More importantly I detailed the issues I see with a pure  
strict type checking only approach.

I am publishing it a bit prematurely imho, but its not without merit  
at this stage either and since I will be busy playing frisbee all  
weekend, I thought I get it out there for people to comment right now:
http://wiki.php.net/rfc/typecheckingstrictandweak

As Paul insisted that my initial proposal did not sufficiently high  
light the fact that there are other proposals, I moved my original  
proposal to the above location so that we can have a disambiguation  
page that lists all the various related proposals:
http://wiki.php.net/rfc/typechecking

Most of that is in there has been said/proposed on the list, so I am  
just pasting the key section on why I think strict checking is  
dangerous:
Strict type checking does have the advantage that subtle bugs will be  
noticed more quickly and that function/method signatures will become  
yet more self documenting and therefore more expressive. Also doing  
these type checks based on the signature also means less code and  
better performance over having to hand code the validation
Proponents of only providing strict type checking say that for the  
most part variables are defined with the proper type unless they come  
from an outside source, which usually requires validation anyways,  
which is a perfect opportunity to type cast.
(Continue reading)

Permalink | Reply | 9 comments |
headers
troels knak-nielsen | 2 Jul 16:11
Gravatar

[PHP-DEV] constructors are callable as regular functions.

I just realised that the following is valid php code:

    class Foo {
      function __construct() {
        echo "constructor called\n";
      }
    }
    $f = new Foo();
    $f->__construct();

Output:

    constructor called
    constructor called

I would have expected the second call to __construct() to yield an error.

Has this been discussed before? In that case, was it decided to go
with this behaviour or is it purely accidental? Are there perhaps some
implementation issues in preventing the second call to __construct()?

--
troels

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 6 comments |
headers
Gwynne Raskind | 2 Jul 12:25

[PHP-DEV] Tiny correction to type hinting patch

In Ilia's type hinting patch, on line 255, is the line:

+<ST_IN_SCRIPTING>"string"|"binary"|"unicode" {

This failed for me. I fixed it by changing it to:

+<ST_IN_SCRIPTING>("string"|"binary"|"unicode") {

Which matches all the other lexing rules for type hints. My  
understanding of the lexer is insufficient to understand why this  
particular set of parenthesis makes any difference at all, but there  
you have it.

-- Gwynne

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Davide Romanini | 2 Jul 10:17

[PHP-DEV] SOAPClient authentication problem

I sent this message to the php.soap newsgroup, but noone answered me.

Today I found a nasty problem with a simple php SOAP client. Never had
problems before, but today I have the following error at SOAPClient
constructor line:

SoapClient::SoapClient(http://www.w3.org/2001/xml.xsd): failed to open
stream: HTTP request failed! HTTP/1.1 401 Authorization Required

The source is as simple as:

$client = new SoapClient("http://my.host.com/my_web_service?wsdl",
                         array( 'trace' => TRUE,
                                'login'=>'mylogin',
                                'password'=>'secret'
                              )
                        );

It seems that the php xml parser tries to fetch the url
http://www.w3.org/2001/xml.xsd at wsdl parsing time. Sniffing the
network operations I found that php uses my login and password (for the
web service) also to access external references! :-O

GET /2001/xml.xsd HTTP/1.0
Authorization: Basic bXlsb2dpbjpzZWNyZXQ=
Host: www.w3.org

In the past probably w3.org just ignored the issue, but now I receive an
HTTP 401 Unauthorized error in response...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Biggar | 2 Jul 04:35

[PHP-DEV] Flexible type hinting

Hi folks,

Thanks to Ilia for getting to ball rolling on scalar type hinting.

It seems there are 3 camps:
  - (C) the type checking camp: "when I say 'int' I mean 'int'". This
is what Ilia's patch does.
  - (H) the type hinting crowd: 'int' is a hint to the user that an
int is expected. This gels well with PHP's weakly typed scalars. I
think few people are in this crowd, but a lot of the (S) crowd are
mistakenly thought to be.
  - (S) the "sensible" middle: 'int' means an integer of course. The
manual is written somewhere between (S) and (H).

I believe I have a solution that caters to each crowd, without being
too complicated.

There are advantages and disadvantage to all of these:

 - The main disadvantage of each system is that it doesnt provide what
the other systems allow. Strong is too strong for many. Weak is too
weak for most.
 - Ilia had a very good point against (H), which is that many
functions return NULL or FALSE, and there are lots of errors when
these are automatically (and silently) converted to 0 or "". (H) will
not catch anything.
 - A strong argument against (C) is that this currently has no
parallel with how scalars are handled in PHP currently.
 - A (I think weak) argument for (C) is that this is how object type
hinting works
(Continue reading)

Permalink | Reply | 37 comments |
headers
Brian A. Seklecki | 2 Jul 00:58

[PHP-DEV] Socket Timeout Documentation

All:

Perhaps we should clarify the socket tuneables such as:

  ; Default timeout for socket based streams (seconds)
  default_socket_timeout = 60

These are slightly ambiguous.  e.g., we should clarify connect()
timeouts v.s. "idle" timeouts.  

There are at least a dozen tickets open related to timeout behavior and
a lot of the confusion results of ambiguity in the variable naming
convention and documentation.

 ~BAS

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Alexander Hjalmarsson | 2 Jul 00:53

[PHP-DEV] CLI benchmark ready for testing

Hi there!

The php CLI benchmark is now pretty much ready for some testing. I'd like
any type of feature feedback and bug reports are appreciated.

There is a brief documentation available at the scratchpad,
http://wiki.php.net/doc/scratchpad/benchmark . It describes the main
features and how it can be used. Keep in mind that the cachegrind tool takes
very long time to execute, so I suggest using only --path microtests if it
is for testing only, since it will be way shorter in that case.

The location of the cvs is http://cvs.php.net/viewvc.cgi/php-benchmarks/ .

Comments are appreciated, good or/and bad :)

Best regards
Alexander
Permalink | Reply | 0 comments |
headers
Josh Thompson | 2 Jul 00:36
Gravatar

[PHP-DEV] RFC: Boxing and Unboxing

Greetings All,

Intro
=====

The discussion over type hinting seems to be getting divided between 
those who really like it (most likely the ones who write strongly typed 
programs anyway) and those who don't want to add yet another kind of 
type system to PHP.

I have been thinking about it and wondered why we don't borrow a concept 
  from C# with a PHP twist of course. The basic idea of boxing in C# is 
that a value type is implicitly converted to an object type. Unboxing is 
  done explicitly to convert the object back to a value type.

Idea
====

I figure instead of adding scalar type hints, we could reuse the object 
type hints to do implicit boxing of variables. Either (but not both) a 
new magic method (``__box`` for example) or a new interface (``Boxable`` 
for example) would need to be added to PHP. The method would accept the 
scalar value and set its internal representation (similar to 
``__wakeup``). The method could either (but not both) return false or 
throw an exception (``BoxingException`` for example).

It is my belief that PHP would need to include as many object versions 
of scalar types as possible. The boxing functionality could be added to 
the SPL Types [1]_ to provide for standard representations of the scalar 
types. However the power to box variables would also be available in
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gelu Kelunden | 1 Jul 19:59

[PHP-DEV] CGI and FastCGI SAPI

Hi,

I'm trying to understand how difficult it is to create a new SAPI, so I 
started to poke my nose inside the "cgi" SAPI source code. I saw that 
"cgi_main.c" implements both the CGI and the FastCGI protocols and I kinda 
got lost inside all those if-else lines (I tried to take out the FastCGI 
code and failed miserably). I'm wondering if it's not better to have 2 
different SAPIs, one for CGI and for FastCGI.

Advantages of this "split" would be:
- the source code will be more readable without all those if-else statements
- we would have 2 executables that do 2 different jobs, unlike now where 
php-cgi does both; each executable could then be further optimized for the 
exact job they are performing

Disadvantages I see:
- maintaning 2 SAPI implementaion would require more work (since CGI and 
FastCGI both share most of the SAPI code, any change would have to be 
replicated twice)
- break backward compatibility (where php-cgi handles both CGI and FastCGI)

Thank you for your time,
Gelu

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 5 comments |
headers
Ilia Alshanetsky | 1 Jul 18:59

[PHP-DEV] RFC: Type hinting revisited for PHP 5.3

There has been quite a bit of discussion on this list, IRC, developer  
meetings, etc... about introduction of type hinting to PHP. Most  
people appear to think that this would be a good idea, but there is a  
reason why it is not in PHP already. The main source of conflict  
appears to be that in some cases typical type hinting is just too  
strict for PHP's typeless nature (most people expect that "1" == 1,  
while int type hint would definitely reject string "1").  Personally,  
I disagree with that opinion, but I can understand people who raise  
that issue. At work we've been using PHP 5.2 with type hinting for  
nearly 2 years now with great success, it makes code much easier to  
read and understand and the security benefit of type hinting is not to  
be under valued. In many cases type hinting can present a last line of  
defense against unexpected input for numeric fields, which are  
typically abused to do SQL injection.

I've taken a few hours this morning to port my 5.2 type hinting patch  
to 5.3. In recognition of a need for a more 'flexible' numeric type  
I've introduced (numeric) type hint that would allow bool/int/float  
data types as well as a string containing a numeric entity as  
identified by is_numeric_string(). For completion i've also added  
(scalar) data type that will allow any scalar data element.

The patch is available here: http://ia.gd/patch/type_hint_53.txt

It should be noted that this patch is fully compatible with opcode  
caches and and requires no changes on the part of an opcode cache such  
as APC to work.

My hope is that the latest changes will allow this to become a  
standard part of PHP.
(Continue reading)

Permalink | Reply | 55 comments |

Gmane