On 1-Jul-09, at 10:35 PM, Paul Biggar wrote:
- A strong argument against (C) is that this currently has no
parallel with how scalars are handled in PHP currently.
It does not need to have a parallel. PHP as a rule is a type flexible
language, my intention is not to change that, simply provi
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
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
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 ca
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
On Wed, Jul 1, 2009 at 10:53 PM, Hannes
Magnusson wrote:
> On Wed, Jul 1, 2009 at 23:36, Paul Biggar wrote:
>> On Wed, Jul 1, 2009 at 10:23 PM, Hannes
>> Magnusson wrote:
>>> On Wed, Jul 1, 2009 at 23:07, Paul Biggar wrote:
So, what you're saying is, the patch already handles coercion? If
Hi!
Type _hinting_ is in no way related to type _casting_.
If you define it as such, there's no scalar type _hinting_ in PHP at all
now. All engine works through _casting_.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
Hi!
You are wrong. Internal type hinting is done in the form of argument
information.
You are confusing arginfo's with zend_parse_parameters types. They work
differently (class typehints are strict, because there's no way to
convert classes from one type to another). These aren't even the sa
On Wed, Jul 1, 2009 at 23:36, Paul Biggar wrote:
> On Wed, Jul 1, 2009 at 10:23 PM, Hannes
> Magnusson wrote:
>> On Wed, Jul 1, 2009 at 23:07, Paul Biggar wrote:
>>> So, what you're saying is, the patch already handles coercion? If
>>> that's the case, then problem solved.
>>
>> The patch offers sc
On Wed, Jul 1, 2009 at 10:23 PM, Hannes
Magnusson wrote:
> On Wed, Jul 1, 2009 at 23:07, Paul Biggar wrote:
>> So, what you're saying is, the patch already handles coercion? If
>> that's the case, then problem solved.
>
> The patch offers scalar type _hinting_. Not type _casting_.
>
> Type hinting
On Wed, Jul 1, 2009 at 23:07, Paul Biggar wrote:
> So, what you're saying is, the patch already handles coercion? If
> that's the case, then problem solved.
The patch offers scalar type _hinting_. Not type _casting_.
Type hinting in PHP works very simply: If the value doesn't type-match
the argum
On Wed, Jul 1, 2009 at 10:02 PM, Hannes
Magnusson wrote:
> On Wed, Jul 1, 2009 at 22:50, Stanislav Malyshev wrote:
>> No, internal typehint doesn't work the way "int" typehint works with this
>> patch. Internal typehint (zend_parse_parameters) do conversions, see
>
> You are wrong. Internal type hi
On Wed, Jul 1, 2009 at 22:50, Stanislav Malyshev wrote:
> No, internal typehint doesn't work the way "int" typehint works with this
> patch. Internal typehint (zend_parse_parameters) do conversions, see
You are wrong. Internal type hinting is done in the form of argument
information.
Those are ide
On Wed, 1 Jul 2009, Ilia Alshanetsky wrote:
>
> 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 contai
Hi!
Right. So we would have two APIs for types - one coercing (for internals)
and one strict (for user functions), which would work in entirely different
way. Is that good?
How is that different from what we have already?
Well, it's different in a way that right now we have typehints only fo
On Wed, Jul 1, 2009 at 22:29, Stanislav Malyshev wrote:
> Hi!
>
>> C does not have booleans, they are emulated via smallint/tinyint. As far
>> as your other message goes, this patch does nothing to affect how native
>> functions handle args.
>
> Right. So we would have two APIs for types - one coer
2009/7/1 Rodrigo Saboya :
> ...I think HEAD is more suited for thoses changes
> rather than 5.3 branch. (But I must confess I loved LSB and Closures in 5.3
> :) )
>
Like said above, it can't (and wont go in 5.3) because it will break ABI
--
regrads,
Kalle Sommer Nielsen
ka...@php.net
--
PHP
Hi!
C does not have booleans, they are emulated via smallint/tinyint. As far
as your other message goes, this patch does nothing to affect how native
functions handle args.
Right. So we would have two APIs for types - one coercing (for
internals) and one strict (for user functions), which wo
Ilia Alshanetsky wrote:
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 a
C does not have booleans, they are emulated via smallint/tinyint. As
far as your other message goes, this patch does nothing to affect how
native functions handle args.
Ilia Alshanetsky
On 2009-07-01, at 2:44 PM, Stanislav Malyshev wrote:
Hi!
As far as your point goes, numeric hint add
On 1 Jul 2009, at 18:59, Ilia Alshanetsky wrote:
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").
To be fair, this is
Any way you guys decide to do it, I think taking learnings and/or code
directly from PHP-FPM could be key to base this off of.
One suggestion might be improving the hooks into PHP so that the
process management component can be done separately. This would allow
for distributions to send it as a se
Ilia Alshanetsky wrote:
> There has been quite a bit of discussion on this list, IRC, developer
> meetings, etc... about introduction of type hinting to PHP.
> [..]
>
> My hope is that the latest changes will allow this to become a standard
> part of PHP.
+1
> [..]
- Mark
--
PHP Internals -
Actually I see it a step forward.
In the beginning, the "cgi" SAPI implemented only the CGI protocol. Support
for FastCGI was added gradually on top of the pure CGI implementation. In
order to test this "non-stable" code, one would have to use
"--enable-fastcgi".
Now FastCGI code is stable e
On Wed, Jul 1, 2009 at 8:04 PM, Stanislav Malyshev wrote:
>> I agree. We won't be able to use an int type for something which
>> should take an int. That might not matter in user code, but if we
>> cannot actually type hint internals functions then its a problem.
>
> Internal functions have types,
Hi!
I agree. We won't be able to use an int type for something which
should take an int. That might not matter in user code, but if we
cannot actually type hint internals functions then its a problem.
Internal functions have types, however parameters of different types are
usually converted,
On Jul 1, 2009, at 2:37 PM, Gelu Kelunden wrote:
I think that the official FastCGI implementation will eventually
evolve into something like PHP-FPM, if not even more.
What I'm saying is that code that handles daemonization (uid/gid/
chroot/log), workers mgmt (spawing/safe-shutdown), daemon c
On Wed, Jul 1, 2009 at 7:44 PM, Stanislav Malyshev wrote:
> Hi!
>
>> As far as your point goes, numeric hint addresses it.
>
> Numeric hint addresses one scenario only. It doesn't address conversions to
> strings or booleans, for example (even C allows you to use int as boolean!
> :).
I agree. We
Hi!
As far as your point goes, numeric hint addresses it.
Numeric hint addresses one scenario only. It doesn't address conversions
to strings or booleans, for example (even C allows you to use int as
boolean! :).
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend
Although this sounds an extremely valid change, it breaks binary so
I'm against on 5.3.
Also, introducing type hints doesn't means that also core functions
should follow it? Because currently '1' is converted to true.
So in microtime for example... it should not support
microtime('true'), but micr
I think that the official FastCGI implementation will eventually evolve into
something like PHP-FPM, if not even more.
What I'm saying is that code that handles daemonization
(uid/gid/chroot/log), workers mgmt (spawing/safe-shutdown), daemon config
file (not php.ini or php-cgi.ini) should not
If you use int type hit "1" will be rejected, but if use numeric type
hint it will be accepted.
Ilia Alshanetsky
On 2009-07-01, at 1:23 PM, Paul Biggar wrote:
Hi Ilia,
This is great.
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetsky
wrote:
I've taken a few hours this morning to port my
Tom,
Type hinting is optional you don't have to use it. However, the
"numeric" type I've added specifically addresses that point.
Ilia Alshanetsky
CIO/CSO
Centah Inc.
On 2009-07-01, at 1:22 PM, Tom Boutell wrote:
I expect this would be a problem for folks who are relying on the fact
that
As far as your point goes, numeric hint addresses it.
Ilia Alshanetsky
CIO/CSO
Centah Inc.
On 2009-07-01, at 2:07 PM, Stanislav Malyshev wrote:
Hi!
The patch is available here: http://ia.gd/patch/type_hint_53.txt
Technical comment: as this patch changes binary API this shouldn't
happen
I think it would be a good idea to also include PHP-FPM in your investigation.
On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelunden wrote:
> 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
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
On Wed, Jul 1, 2009 at 18:59, Ilia Alshanetsky wrote:
> The patch is available here: http://ia.gd/patch/type_hint_53.txt
It is missing minor build fix for ext/reflection, see
http://pastebin.com/f50db9aa1
Other then that, I'm definitely +1 on this
-Hannes
--
PHP Internals - PHP Runtime Develop
Hi!
The patch is available here: http://ia.gd/patch/type_hint_53.txt
Technical comment: as this patch changes binary API this shouldn't
happen in 5.3 branch. So maybe it's better to make it for 6.
As for the idea itself, it is obvious that many people like it, I would
just note that it wou
+1000 * infinity plus one
On Jul 1, 2009, at 12:23 PM, Paul Biggar wrote:
Hi Ilia,
This is great.
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetsky
wrote:
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 t
Hi Ilia,
This is great.
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetsky wrote:
> 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
Yes 5.3.1 is definitely not the right time frame for a backwards
incompatible change.
On Wed, Jul 1, 2009 at 1:17 PM, Sebastian
Bergmann wrote:
> Ilia Alshanetsky schrieb:
>> about introduction of type hinting to PHP
>
> About the "introduction of scalar type hinting" you mean? :-)
>
> I am all
It also makes type analysis for potential compile time optimizations much
easier. It reduces the unknowns that occure from functions! This is
something that could be a big help with that.
On Wed, Jul 1, 2009 at 10:15 AM, Alain Williams wrote:
> On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alsh
This is great! I've always wanted to see optional type hinting for PHP.
On Wed, Jul 1, 2009 at 10:09 AM, Gwynne Raskind wrote:
> On Jul 1, 2009, at 12:59 PM, Ilia Alshanetsky wrote:
>
>> There has been quite a bit of discussion on this list, IRC, developer
>> meetings, etc... about introduction o
I expect this would be a problem for folks who are relying on the fact
that they can parse configuration files and web inputs purely as
strings, yet numeric fields containing string representations of
numbers will actually behave as numbers if called upon to do so.
Speaking of which, when I'm in a
Ilia Alshanetsky schrieb:
> about introduction of type hinting to PHP
About the "introduction of scalar type hinting" you mean? :-)
I am all for this, but I think it would be wrong to add this in 5.3.X.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebast
On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote:
> 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
On Jul 1, 2009, at 12:59 PM, Ilia Alshanetsky wrote:
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 alread
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
Hi all,
anybody knows, how to build especially pdo_mysql with libmysql on Windows
(I've managed to build mysql and mysqli with a change in the config.w32 files)?
My configure string is something like:
| cscript /nologo configure.js --disable-all \
| ... \
|
Sebastian Bergmann wrote:
> Greg Beaver schrieb:
>> First, add "-drequire_hash=0" to go-pear.bat as a temporary fix for
>> those who already have PHP 5.3.0, and the permanent fix is to
>> re-generate the go-pear.phar on a machine with ext/phar installed.
>
> That should have been "-d phar.require
Greg Beaver schrieb:
> First, add "-drequire_hash=0" to go-pear.bat as a temporary fix for
> those who already have PHP 5.3.0, and the permanent fix is to
> re-generate the go-pear.phar on a machine with ext/phar installed.
That should have been "-d phar.require_hash=0", I guess.
--
Sebastian B
Christian Weiske wrote:
> Hi,
>
>
> Several users reported that the windows package of php 5.3 does not work with
> the phar:
> - http://pastebin.com/d79a424b3
> - http://pastebin.com/d49c8cc02
>
> phar "C:\Users\Sebastian Bergmann\php\PEAR\go-pear.phar" does not have a
> signature
> Warning: req
Uwe Schindler wrote:
I had the same this morning when I compiled PHP on my solaris machine. The
php.ini from my system-wide lib folder was used for the tests. In my case it
claimed about the deprecated *_long_arrays setting (or something like that).
Almost no test worked until I edited my global
On Wed, Jul 1, 2009 at 08:05, Kalle Sommer Nielsen wrote:
> 2009/6/30 Hannes Magnusson :
>> Like I warned about; if you enable any of these features in your
>> php.ini and then run the test suite.. there are only a handful of
>> tests that actually pass.
>
> I can see us passing -n parameter to the
54 matches
Mail list logo