On 04.06.2010, at 03:18, Daniel Convissor wrote:
> On Thu, Jun 03, 2010 at 10:29:30AM -0400, Daniel Convissor wrote:
>> Hi Folks:
>>
>> On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote:
>>>
>>> IMHO we shouldn't be getting to any kind of fatal error/exception
>>> situation, which
Hello,
i am working on a webfrontend for php itself.
For example i have a little script that writes ini settings into ini.php.
I am using normal vars to write the variables into the ini file.
yours sincerly
Alexander Schunk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
Hi!
function call chaining (f()() if f() returns function), and array
dereferencing (f()[0]) - (Stas)
I did patch for f()() - it's referenced at
http://wiki.php.net/rfc/fcallfcall - but not for f()[] - didn't have
time for that yet.
It should not be too hard to do, one just has to be caref
On 06/02/2010 10:03 PM, John LeSueur wrote:
On Wed, Jun 2, 2010 at 1:37 PM, Michael Wallner wrote:
Now the script:
typo: shouldn't this be $b/1024/1024?
doh! :) You're right, but it doesn't really change anything in the comparison.
Regards,
Mike
--
PHP Internals - PHP Runtime Developme
2010/6/4 Tig :
> On Fri, Jun 4, 2010 at 11:19 AM, Kalle Sommer Nielsen wrote:
> So does this mean array-dereferencing was original declined but still
> a possible for PHP 6?
> That is how I'm reading it, but just want to make sure.
I belive its because when its been proposed countless times on th
Hi,
I've always wondered the same thing too. Would be a nice improvement.
- Jon
On Thu, Jun 3, 2010 at 9:12 PM, Tig wrote:
> Would be at all possible to implement this kind of shortcut?
>
> echo function(var)[0];
>
> For example, to print the height of an image:
> echo getimagesize('./path/t
Hi,
Has anyone attempted a patch for this? Or does anyone have an idea of
the feasibility? Is it technically possible in a good/clean way?
- Jon
On Thu, Jun 3, 2010 at 9:29 PM, Tig wrote:
> On Fri, Jun 4, 2010 at 11:19 AM, Kalle Sommer Nielsen
> wrote:
> > Hi Tig
> >
> > 2010/6/4 Tig :
> >> W
On Fri, Jun 4, 2010 at 11:19 AM, Kalle Sommer Nielsen wrote:
> Hi Tig
>
> 2010/6/4 Tig :
>> Would be at all possible to implement this kind of shortcut?
>
> Its called array-dereferencing and it was proposed countless times,
> including by myself. There is an RFC for this[1] and it was planned on
Hi Tig
2010/6/4 Tig :
> Would be at all possible to implement this kind of shortcut?
Its called array-dereferencing and it was proposed countless times,
including by myself. There is an RFC for this[1] and it was planned on
the old PHP6 todo at the PDT[2].
[1] http://wiki.php.net/rfc/functionarr
On Thu, Jun 03, 2010 at 10:29:30AM -0400, Daniel Convissor wrote:
> Hi Folks:
>
> On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote:
> >
> > IMHO we shouldn't be getting to any kind of fatal error/exception
> > situation, which is why I like the idea of auto-conversion plus E_STRICT
Would be at all possible to implement this kind of shortcut?
echo function(var)[0];
For example, to print the height of an image:
Sure, if you want more than one of the returned array points, this
would not be very efficient, however when you do only need one, it
would be a lot nicer than:
A
Take over the control of the Validate_ES and Date_Holidays_Spain packages in
the Pear repository. I'm now leader of Date_Holidays_Spain package, and soon
will be the maintainer of Validate_ES
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub
On 3 June 2010 23:37, Stas Malyshev wrote:
> Validation and typing are entirely different things. Many validation methods
> do not require or provide strict typing.
I can't agree more and that's exactly why I want typehints to only
check for type, not validate the content of a variable. An "integ
Hi!
And remember that I was only discussing it in response to the claim
that "almost all incoming data for PHP are strings." My point was that
user input will be correctly typed if you validate it with PHP's
bundled extension, as it is commonly recommended, and it's also
Validation and typing
On 3 June 2010 22:24, Gustavo Lopes wrote:
> On Thu, 03 Jun 2010 17:25:53 +0100, Josh Davis wrote:
>
>> The only other big source of data is the database. [...]
Emphasis on "big." There's an infinite number of sources (from mashups
using XML or JSON to XML-RPC servers or weird setups processing
Am I missing something or can't you just add another set of function pointers
to the PDO driver and statements like:
driver_methods = {
...
pg_copy_from, /* OR NULL IF NOT SUPPORTED */
pg_copy_to
};
statement_methods = {
...
pg_copy_to
};
Then if the driver does not impl
Hi.
It is similar to what I tried to do with the pgsql driver (look at my previous
post).
I could try to restore the old patch, compare with your and then re-test it.
If this is the way to follow, then the optimal solution (?) would be to add a
standard function to the pdo driver that translat
On Thu, 03 Jun 2010 17:25:53 +0100, Josh Davis wrote:
On 1 June 2010 20:43, Stas Malyshev wrote:
It is very frequent that you want number and get "1" instead - almost
all incoming data for PHP are strings.
I'd like to point out that filter_input() does cast user input to the
right PHP type
Hi.
I tried to add to the PDO pgsql driver a method that, in our intention, should
have returned the connection resource after registering it as zend resource.
Basically, the method did the following call:
ZEND_REGISTER_RESOURCE(return_value, H->server, le_link);
(H->server is the post
On Thu, 2010-06-03 at 21:48 +0200, Denis Gasparin wrote:
> As I wrote last week, according to me too the best solution
> would be to share the PDO opened connection between the old
> pgsql driver and the PDO one
> That was the original way we tried to develop the patch
> without success.
Would
Hi,
On Thu, Jun 3, 2010 at 3:48 PM, Denis Gasparin
wrote:
>
> As I pointed out last week, we needed these functions for several reasons:
>
> - the same features are not available directly via sql commands.
> - we needed PDO in order to use the doctrine framework but we needed to
> verify the tran
As I pointed out last week, we needed these functions for several reasons:
- the same features are not available directly via sql commands.
- we needed PDO in order to use the doctrine framework but we needed to verify
the transaction status and use the pgsql copyFrom/To functions
- for performa
On Thu, Jun 3, 2010 at 8:47 PM, Ferenc Kovacs wrote:
> This discussion has a long history, and it would be better to actualy do
> something about the problem, because it seems that it won't going to
> disappear by itself.
> I don't want to be rude, but the PDO v2 spec was last modified in
> 2008.
On Thu, Jun 3, 2010 at 8:17 PM, Pierre Joye wrote:
> On Thu, Jun 3, 2010 at 7:58 PM, Ferenc Kovacs wrote:
>
> > So?
> > Now we shouldn't try to improve things because they aren't perfect?
>
> Because it is a very bad thing, by design and we will have to keep it
> during years. I think this exact
On Thu, Jun 3, 2010 at 7:58 PM, Ferenc Kovacs wrote:
> So?
> Now we shouldn't try to improve things because they aren't perfect?
Because it is a very bad thing, by design and we will have to keep it
during years. I think this exact point was clear enough.
>> We need to stop this and start fixin
On Thu, Jun 3, 2010 at 7:28 PM, Jonathan Wage wrote:
> Hi,
>
> On Thu, Jun 3, 2010 at 1:16 PM, Ferenc Kovacs wrote:
>
>> If that so, I would be happy to see some discussion and work on the PDO,
>> because from a user perspective, it seems like abadoned.
>> I think that we should allow to get thi
Hi,
On Thu, Jun 3, 2010 at 1:16 PM, Ferenc Kovacs wrote:
> If that so, I would be happy to see some discussion and work on the PDO,
> because from a user perspective, it seems like abadoned.
> I think that we should allow to get things commited, because:
> 1, the trunk is a trunk, if something g
If that so, I would be happy to see some discussion and work on the PDO,
because from a user perspective, it seems like abadoned.
I think that we should allow to get things commited, because:
1, the trunk is a trunk, if something gets commited, it doesn't mean, that
it will be merged for the releas
On 3 June 2010 18:25, Josh Davis wrote:
> seems that mysqlnd experiments in using MySQL's binary protocol for
> all queries and not just prepared statements [1] didn't materialize.
I have to correct myself here, the MYSQLI_OPT_INT_AND_FLOAT_NATIVE
option did materialize, so native typing through
On 03.06.2010, at 18:57, Ferenc Kovacs wrote:
>
>
> On Thu, Jun 3, 2010 at 6:32 PM, Lukas Kahwe Smith wrote:
>
> On 03.06.2010, at 18:25, Josh Davis wrote:
>
> > On 1 June 2010 20:43, Stas Malyshev wrote:
> >
> >> It is very frequent that you want number and get "1" instead - almost
> >> al
On Thu, Jun 3, 2010 at 6:32 PM, Lukas Kahwe Smith wrote:
>
> On 03.06.2010, at 18:25, Josh Davis wrote:
>
> > On 1 June 2010 20:43, Stas Malyshev wrote:
> >
> >> It is very frequent that you want number and get "1" instead - almost
> >> all incoming data for PHP are strings.
> >
> > I'd like to p
Hi,
I really think that we should consider the long term ramifications of these
changes. If we do implement database specific features now and continue to
implement more in the future, we can't possibly think it is a good idea to
just dump them all in the global PDO namespace. This would be a deva
On 03.06.2010, at 18:25, Josh Davis wrote:
> On 1 June 2010 20:43, Stas Malyshev wrote:
>
>> It is very frequent that you want number and get "1" instead - almost
>> all incoming data for PHP are strings.
>
> I'd like to point out that filter_input() does cast user input to the
> right PHP typ
On 1 June 2010 20:43, Stas Malyshev wrote:
> It is very frequent that you want number and get "1" instead - almost
> all incoming data for PHP are strings.
I'd like to point out that filter_input() does cast user input to the
right PHP type. And if memory serves, ext/filter is meant to be PHP's
Hi.
Did you have the time to review the patches? Any problem with them?
Thank you in advance,
Denis
- Messaggio originale -
> Da: "Denis Gasparin"
> A: "Ilia Alshanetsky" , "Matteo Beccati"
> Cc: internals@lists.php.net, "pdo"
> Inviato: Mercoledì, 26 maggio 2010 13:11:17
> Oggetto:
At first I would like to help translate the documentation in Italian,
simultaneously or later (as needed) I would like to help in the maintenance of
the website.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Folks:
On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote:
>
> IMHO we shouldn't be getting to any kind of fatal error/exception
> situation, which is why I like the idea of auto-conversion plus E_STRICT
> in the 'weird conversion' scenarios
E_STRICT doesn't cut it. So many appli
37 matches
Mail list logo
