Re: [PHP-DEV] [RFC] JSON number to string

[Alexey Zakhlestin]

> On 25 May 2015, at 18:40, Jakub Zelenka  wrote:
> 
>> Anyway, as I told in a previous thread, while approach of this rfc solves 
>> immediate problem, it is not future-proof flexible and exposing low-level 
>> type based parsing is a better idea
>> 
> IIRC your initial proposal was about converting everything to objects which 
> is not flexible at all as it suffers exactly from the same problems as this 
> RFC. The only difference is using object instead of string. I think that the 
> above is much more flexible...
> 
> However as I said before it is quite a big feature that could be done only in 
> the minor version and requires considerably more time for implementation.

The difference is, that object would preserve type information from the 
document. Source representation would always be the string, but you will be 
able to know if it was typed as a Number or as a literal String. After that, 
application’s logic can decide what it should do with it.

But yeah, sure, that is a bigger feature

А.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JSON number to string

[Alexey Zakhlestin]

> 24 мая 2015 г., в 19:02, Jakub Zelenka  написал(а):
> 
> Hi,
> 
> I would like to introduce my and Pasindu's RFC that proposes adding of new
> JSON options for converting number values to string when decoding and/or
> encoding:
> 
> https://wiki.php.net/rfc/json_numeric_as_string
> 
> Personally I'm not a big fun of these options because of their drawbacks
> (see RFC section about that) and because I think that Json Scheme is a
> better way to go. However I'm not sure when and if I have time for Json
> Schema implementation, so this could be useful for some users the meantime.
> That is especially case of JSON_FLOAT_TO_STRING for decoding (encoding is a
> bit weird at it requires usage ini precision to do something useful). That
> (decoding) seems like a sort of a variant of JSON_BIGINT_TO_STRING for
> floats. That will be probably the only option that I will be vote for.

I'm not sure how JSON Schema would help here. The issue is about converting 
from json's huge numbers to limited PHP's numbers. Schema just doesn't have 
notion of native types

Anyway, as I told in a previous thread, while approach of this rfc solves 
immediate problem, it is not future-proof flexible and exposing low-level type 
based parsing is a better idea 
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

[Alexey Zakhlestin]

> On 23 Apr 2015, at 14:26, Alexander Moskalev  wrote:
> 
> Because currently CURLFile have this constructor:
> public __construct  (
> string $filename [, string $mimetype [, string $postname ]] )
> 
> And we cannot replace this arguments to avoid BC break.

(Do not top-post please.)

Well… We can introduce another class, which would inherit from CURLFile.
Similar to how SplTempFileObject extends SplFileObject.



А.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

[Alexey Zakhlestin]

> On 23 Apr 2015, at 11:59, Michael Wallner  wrote:
> 
> Why not a ctor as in:
> 
> function __construct ($filename, $buffer = null) {
>if (isset ($ buffer)) {
>// use $ buffer
>} else {
>// use file contents
>}
> }
> 
> The file name parameter can be of use anyway for posted file contents from
> buffer.

Looks good! So, it work like this (+ error handling)

function __construct($filename, $buffer = null)
{
$this->filename = $filename;

if (is_null($buffer)) {
$this->data = file_get_contents($filename);
} else {
$this->data = buffer;
}
}



А.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] JSON float number as string

[Alexey Zakhlestin]

> On 14 Apr 2015, at 07:31, Alexey Zakhlestin  wrote:
> 
> Feels a bit hackish
> I think it is possible to introduce an overall better solution
> 
> We can expose result of json-tokenizing as a tree of objects:
> 
> JSON\Object
> JSON\Array
> JSON\String
> JSON\Number
> JSON\False
> JSON\True
> JSON\Null
> 
> then, it would be possible to introduce any number of experimental userland 
> implementations like the one proposed here

I decided to elaborate

toString();
}
}

class String extends Literal
{
}

class Number extends Literal
{
public function toInt();
public function toFloat();
}

class False extends Literal
{
}

class True extends Literal
{
}

class Null extends Literal
{
}


So, in case of Number, there would be a way to get the value the way it was 
stored in document using toString(), use toInt() or toFloat() to get a value 
with possible precision loss or use toNative(), which would be “smart” and 
return int or float using the same logic, which json_decode() uses now.

It would work the other way round too. Object::toJson() would return 
json-representation of the tree.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] JSON float number as string

[Alexey Zakhlestin]

> On 29 Mar 2015, at 22:33, Jakub Zelenka  wrote:
> 
> I would like to add a new option to JSON for dealing with large floats. The
> use case is mainly for decoder but can be used for encoder as well.
> 
> JSON_FLOAT_AS_STRING
> decode: all float values will be decoded as string
> - It's often an issue for very large float values with many fractional
> digits that are coming from platforms that support larger float
> representation than double. In that case the conversion is lost and there
> is no way how to get it back (see http://bugs.php.net/68456 [pls ignore my
> initial dump comments when I didn't get the issue :)] and an example of the
> lost precision here http://3v4l.org/80iCh ). Converting the value to string
> keep the precision and resolves the problem.
> 
> encode: all float values will be encoded as string
> - re-using the constant for encoder makes sense if PHP creates JSON for
> platform that support lower float type (e.g. C float) and the precision
> loss is not acceptable
> 
> 
> I think that this is more a bugfix as the precision is lost without any way
> how to get it back (except pre-processing json string with regular
> expression). I would like to add it to 5.6.x if there are no objections?

Feels a bit hackish
I think it is possible to introduce an overall better solution

We can expose result of json-tokenizing as a tree of objects:

JSON\Object
JSON\Array
JSON\String
JSON\Number
JSON\False
JSON\True
JSON\Null

then, it would be possible to introduce any number of experimental userland 
implementations like the one proposed here

-- 
Alexey Zakhlestin
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] static constructor

[Alexey Zakhlestin]

> On 12 Mar 2015, at 19:28, Larry Garfield  wrote:
> 
> I thought it sounded familiar.  Also check the list archive for "A modest 
> proposal: __constructStatic" from a month ago.  It was rejected then, too.
> 
> Really, I cannot think of any cases where I want to have a static class 
> self-initialize with global data (because all statics are just globals with a 
> fancy dress) where I wouldn't slap myself for being stupid and not just 
> making a proper object, factory, DI, or any number of other options are are 
> 10x more testable and reusable and verifiable.  Sure there's places you could 
> use it; there's just much better options already available in the language 
> and have been for a decade.

I guess it’s just “dreaming” about classes, which are first-class citizens, 
like in smalltalk/ruby/python :-)
But this is just an approximation, anyway.

Real class-objects probably would never happen in PHP.

-- 
Alexey Zakhlestin
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] static constructor

[Alexey Zakhlestin]

> On 12 Mar 2015, at 02:21, Johannes Ott  wrote:
> 
> So now I want to do my first own proposal for a new function in PHP and
> I hope doing it right with starting a discussion here first.
> 
> The purpose of this suggestion is to introduce a static constructor,
> which is called before the first call to class either static or
> non-static to initialize some static properties which are needed by the
> class.
> 
> I think about two different possible syntax to realize that purpose:
> 
> Version 1 (similar to Java):
> 
> class A {
>private static $var;
> 
>static {
> //Do some code here to initialize self::$var;
>}
> 
> }
> 
> Version 2 (a new magic method):
> 
> class B {
>private static $var;
> 
>private static function __static() {
>//Do some code here to initialize self::$var;
>}
> }
> 
> My prefered code would be version 2 at the moment.
> 
> Looking forward to your feedback,

What about inheritance?
I think dynamic class-constructor would make much more sense.
A function which can analyse real class and do initialisation.

class A
{
protected static function __class_construct()
{
echo get_called_class().” class is defined\n";
}
}

class B extends A
{
}

 output 
A class is defined
B class is defined

-- 
Alexey Zakhlestin
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Exceptions in the engine

[Alexey Zakhlestin]

> On 19 Feb 2015, at 12:54, Dmitry Stogov  wrote:
> 
> I think we may introduce the following hierarchy
> 
> abstarct class BaseException {
> }
> class Exception extends BaseException {
> }
> class EngineException extends BaseException {
> }
> 
> the existing code that caught Exception is going to be unaffected.
> New code may decide to catch engine exception in separate catch block
> (using EngineException) or in single block (using BaseException)

If I remember it correctly, BaseException was used by some real code out there.
But we can use _BaseException instead

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [PATCH] Remove useless tests

[Alexey Zakhlestin]

> On 20 Jan 2015, at 21:00, Joshua Rogers  wrote:
> 
> Respective variables are unsigned and cannot be <0.

Did you mean to use “==“ in comparisons?


> ---
> sapi/litespeed/lsapilib.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/sapi/litespeed/lsapilib.c b/sapi/litespeed/lsapilib.c
> index 2e60701..20279d1 100644
> --- a/sapi/litespeed/lsapilib.c
> +++ b/sapi/litespeed/lsapilib.c
> @@ -1442,16 +1442,16 @@ int LSAPI_ReqBodyGetLine_r( LSAPI_Request * pReq, 
> char * pBuf, size_t bufLen, in
> char * pBufCur = pBuf;
> char * pCur;
> char * p;
> -if (!pReq || (pReq->m_fd ==-1) ||( !pBuf )||(bufLen < 0 )|| !getLF )
> +if (!pReq || (pReq->m_fd ==-1) ||( !pBuf )|| !getLF )
> return -1;
> *getLF = 0;
> while( (left = pBufEnd - pBufCur ) > 0 )
> {
> 
> len = pReq->m_bufRead - pReq->m_bufProcessed;
> -if ( len <= 0 )
> +if ( len = 0 )
> {
> -if ( (len = readBodyToReqBuf( pReq )) <= 0 )
> +if ( (len = readBodyToReqBuf( pReq )) = 0 )
> {
> *getLF = 1;
> break;
> @@ -1486,7 +1486,7 @@ ssize_t LSAPI_ReadReqBody_r( LSAPI_Request * pReq, char 
> * pBuf, size_t bufLen )
> ssize_t len;
> off_t total;
> /* char *pOldBuf = pBuf; */
> -if (!pReq || (pReq->m_fd ==-1) || ( !pBuf )||(bufLen < 0 ))
> +if (!pReq || (pReq->m_fd ==-1) || ( !pBuf ))
> return -1;
> 
> total = pReq->m_reqBodyLen - pReq->m_reqBodyRead;
> @@ -1517,7 +1517,7 @@ ssize_t LSAPI_ReadReqBody_r( LSAPI_Request * pReq, char 
> * pBuf, size_t bufLen )
> pBuf += len;
> bufLen -= len;
> }
> -else if ( len <= 0 )
> +else if ( len = 0 )
> {
>     if ( !total)
> return -1;
> --
> 1.9.1
> 
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend

[Alexey Zakhlestin]

> On 19 Jan 2015, at 07:52, Rasmus Lerdorf  wrote:
> 
> On 01/18/2015 02:08 PM, Rasmus Lerdorf wrote:
>> We have to be really really careful with this "oh, that code is wrong,
>> so we can break it argument". This will break hundreds if not thousands
>> of sites in a hard-to-debug way. It took me less than a minute of
>> looking on Github to find a case that will break:
>> 
>> https://github.com/chenboking/service.downloadmanager.amule/blob/cda510415f9a58660e096a7de42b3ea6f39ee851/webserver/php-default/amuleweb-main-search.php#L121
>> 
>> It is extremely common to just do a less-than or a greater-than check in
>> a user comparison function. Of course it isn't textbook-correct, but
>> since it has always worked, people do it.
> 
> And just to further illustrate this, I just downloaded the current
> Wordpress release and sure enough, Wordpress would also be broken by
> this change.
> 
> In http://core.svn.wordpress.org/trunk/wp-includes/class-simplepie.php
> look at the sort_items() method:
> 
>   /**
>* Sorting callback for items
>*
>* @access private
>* @param SimplePie $a
>* @param SimplePie $b
>* @return boolean
>*/
>   public static function sort_items($a, $b)
>   {
>   return $a->get_date('U') <= $b->get_date('U');
>   }
> 
> I am not saying we should revert the change, but we need to be very
> aware of the effect this change will have on PHP7 adoption. The really
> nasty part is that even if a big codebase has unit tests covering the
> code, unless the unit test actually tests an array with more than 16
> elements, all tests will pass and the application will only fail in
> production with production data. And there are no errors or warnings of
> any sort either that will help people track this down.
> 
> This will need to be front and center in the UPGRADING doc with an
> explanation about how to write a proper ordering function.

Should we add E_STRICT for cases when comparison-function returns non-integer 
value?
Having it in stable version should help to fix such anti-patterns in a long-run

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7

[Alexey Zakhlestin]

> On 21 Dec 2014, at 16:53, Alain Williams  wrote:
> 
> On Sun, Dec 21, 2014 at 02:30:28PM +0100, Nikita Popov wrote:
> 
> 
>> Please take a look at the WordPress version statistics:
>> https://wordpress.org/about/stats/
>> 
>> According to these statistics 72% of the WordPress installations are
>> running on either PHP 5.2 or PHP 5.3. This means that they do not benefit
>> from the quite substantial performance and memory usage improvements that
>> went into PHP 5.4. So, if people aren't willing to upgrade from PHP 5.2/5.3
>> to PHP 5.4, I don't see how they'd be more interested in PHP 7.
> 
> I am running PHP 5.3.3 on my servers. Why ?
> 
> Summary: running newer versions is a lot of effort.
> 
> I run CentOS 6 so I run the PHP that is packaged for it. While it might be 
> nice
> to have PHP 5.6 it would involve me in a lot of work (compile from source) 
> and I
> would need to do that with each new release/patch. As it is I just go 'yum
> update' and security fixes, ..., are all installed - easy peasy.

did you hear about RHSCL?
http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/

it solves this usecase nicely


--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736

[Alexey Zakhlestin]

> On 03 Nov 2014, at 02:21, Dan Ackroyd  wrote:
> 
> On 2 November 2014 15:10, Rowan Collins  wrote:
>> Wait, what does session handling have to do with any of this?
> 
> Sorry, I completely failed to write what I was trying to say there.
> 
> I meant that like the session handling functions and setcookie are
> similar in that:
> 
> * They don't feel that nice to use.
> * The exact behaviour of them is currently correct but doesn't cater
> for higher level logic e.g. making a script setting the same cookie be
> an error rather than accepting it.
> 
> Both of them could probably do with being made nicer - but that can be
> done in user-land. There's no _need_ to fix them in the core
> libraries.

well, one thing which could be done is decoupling building of cookie-header 
from adding this header to the response.

setcookie(…) = header(build_cookie_header(…))

this would be much closer to what I would call a low-level API


-- 
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

[Alexey Zakhlestin]

On 14 Jul 2014, at 18:57, Andrea Faulds  wrote:

> On 14 Jul 2014, at 15:54, Derick Rethans  wrote:
> 
>> A compromise by adding more inconsistencies.
>> 
>> I can buy the cast of scalars vs hint--of-complex types, but definitely
>> not the introduction of a new group of casting rules. Keep it simple.
> 
> It doesn’t change the casting rules; write an error handler that ignores 
> E_RECOVERABLE_ERROR and you get exactly the same result as a manual cast 
> inside the function. Rather, it simply adds validation. The casting works 
> like casting does everywhere else, but there’s strict lossless validation on 
> the type hint, similar to the non-scalar type hints except more lenient as it 
> allows equivalent values of other types.

ok, it might work for me if formulated like this.

now, the question is, would it be possible to port these rules to zpp in 
PHP-Next?
if the answer is “yes", then I’m all for it.

otherwise, I’m a bit skeptical as inconsistency between extension-land and 
user-land code worries me

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

[Alexey Zakhlestin]

On 14 Jul 2014, at 16:58, Andrea Faulds  wrote:

> One of the issues with the RFC as it stands is how to handle bool casting. 
> While int, float and string only allow lossless casting (with the exception 
> of objects, but we can’t really do anything about that), bool’s behaviour at 
> the moment is quite different. I don’t think it makes sense so I won’t 
> discuss the current behaviour, only possible new ones.
> 
> One option is simply to forget about being lossless and make the bool type 
> hint accept any value, meaning any truthy value or any falsey value would 
> yield what is expected without error. This would ensure that if some stupid 
> programmer (like myself ;) has passed in a non-boolean truthy/falsey value to 
> your function, it’ll be handled correctly. It would mean all your bit hacks 
> ($foo & FLAG etc.) would work, anything you got from $_GET (e.g. ?foobar=1). 
> However, this is unlikely to catch bugs in code, because literally any PHP 
> value would work. For that reason, I’m not sure this is the way forward.

I don’t think that "scalar casts” should do any additional error-catching. they 
target a very different usecase.
It shouldn’t guarantee correctness of the whole program. It should guarantee 
that variable types are fixed inside of function.

In my opinion, this patch should act 100% similar to zpp.
And if, at some later point zpp-behaviour changes similar change should happen 
to userland "scalar casts"

Some people talk about inconsistency, which is introduced by reusing same 
syntax for "strict parameter types" and "scalar parameter casts”. There’s some 
truth there.
Let’s use different syntax.

This might work:

function foo((int) $a)
{
    var_dump($a);
}

I would read it as declaration-level casting

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing PUT data)

[Alexey Zakhlestin]

On 02.10.2013, at 15:12, Leigh  wrote:

> On 2 October 2013 08:31, Michael Wallner  wrote:
>> 
>> I had it, but I'm not sure $_BODY fits either, because it should be an
>> array. Currently only form data fits the purpose of de-serialisation
>> of a request body.
>> 
> 
> Not so sure about that. I don't think there is a rule that says a body
> _has_ to be in query string name=value format, or that multipart
> elements _have_ to have a name=something attribute. I could quite
> easily imagine PUT requests containing a textual body without an
> associated field name (the URI would contain the field name).
> 
> (correct me if I'm wrong)


In these cases, Content-type of body would different.
And proposal mentions that interpretation should happen strictly basing on the 
content type


-- 
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing PUT data)

[Alexey Zakhlestin]

On 02.10.2013, at 11:24, Michael Wallner  wrote:

> On 2 October 2013 09:17, Alexey Zakhlestin  wrote:
> 
>> 3. expose body-parsers via php-level API
>> 
>>  +1. Hell, yes! Something like +1000, actually ;)
> 
> Uhmmm... I actually meant an interal API not userland :)

well, why not both? :)

string/stream in, array out


-- 
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing PUT data)

[Alexey Zakhlestin]

On 02.10.2013, at 10:59, Michael Wallner  wrote:

> Since ever people are confused by _GET and _POST superglobals,
> because, despite their name, they do not (really) depend on the
> request method.  Therefor I propose to phase out $_GET and name it
> $_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not
> 100% confident with the latter yet, though).
> 
> Further, I propose to remove the POST method restriction for handling
> request bodies and solely rely on the content type to trigger the
> parser(s). (*)
> 
> There are already parsers for application/x-www-form-urlencoded and
> multipart/form-data in the core.  One could think of providing an API
> to add content type handlers from extensions, ext/json may be an
> example, like it is hacked into pecl_http-v2.
> 
> Thoughts, objections, insults?
> 
> (*) We'd probably have to revisit all *post* INI variables, though.

So, that is not one, but three proposals:

1. _GET -> _QUERY, _POST -> _FORM

  I don't think this is really necessary. Names are there historically and 
changing them will break a lot of stuff.
  +0 on aliasing, and soft-deprecation (via documentation) though

2. ignore request-method, trigger body-processing solely on Content-type

  +1. makes sense

3. expose body-parsers via php-level API

  +1. Hell, yes! Something like +1000, actually ;)



-- 
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [VOTE] Change crypt() behavior w/o salt

[Alexey Zakhlestin]

On 24.09.2013, at 5:41, Yasuo Ohgaki  wrote:

> Hi all,
> 
> It's been a whole from the discussion.
> I setup vote for RFC: Change crypt() behavior w/o salt.
> 
> https://wiki.php.net/rfc/crypt_function_salt
> 
> If I missed something, please let me know.

strangely, this RFC is not shown in "In voting phase" section here: 
https://wiki.php.net/rfc
is that done manually?


-- 
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [RFC] Skipping parameters take 2

[Alexey Zakhlestin]

On Tue, Sep 3, 2013 at 11:47 AM, Lester Caine  wrote:
> Robert Williams wrote:
>>
>> PHPDoc doesn't support parameter blocks, which means that IDEs can't offer
>> the same level of assistance with code-completion that they offer for both
>> objects and straight parameters -- another huge downside.
>
>
> PHPDoc's does 'not' not support parameter blocks ... you just document them
> properly in the first place. Switching these to formalised objects
> introduces another level of complexity that detracts from their use rather
> than enhancing it, but again that is more to do with maintaining BC.
> Something that has become a second class citizen nowadays?

PSR-5 (draft) does support them:

https://github.com/phpDocumentor/fig-standards/blob/master/proposed/phpdoc.md#7-describing-hashes


-- 
Alexey Zakhlestin,
http://github.com/indeyets

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Importing namespaced functions

[Alexey Zakhlestin]

On 19.07.2013, at 21:29, Igor Wiedler  wrote:

> Hello internals,
> 
> I posted the initial idea for a use_function RFC a few months back. I would 
> like to make the proposal official now, and open it for discussion.
> 
> I also did some work on a patch that probably still has some issues. Review 
> on that is welcome as well.
> 
> RFC: https://wiki.php.net/rfc/use_function
> Patch: https://github.com/php/php-src/pull/388


I don't see much space for discussion :)
It's a very useful addition with nice explicit semantics and a small patch.

+1

-- 
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] execute compressed PHP command-line application

[Alexey Zakhlestin]

On 18.07.2013, at 12:38, crankypuss  wrote:

> I've been using PHP for linux command-line applications.  Some are quite 
> large.  I've built the code to combine the mainline plus everything it calls 
> into a single file to avoid portability issues with include libraries.  I've 
> built the code to compress the resulting file using gzdeflate after 
> optionally stripping comments and excess whitespace.

didn't you just reinvent the PHAR?

http://docs.php.net/manual/en/intro.phar.php

Phar archives are best characterized as a convenient way to group several 
files into a single file.
As such, a phar archive provides a way to distribute a complete PHP 
application in a single file
and run it from that file without the need to extract it to disk. 
Additionally, phar archives can
be executed by PHP as easily as any other file, both on the commandline and 
from a web server.

The Phar extension is built into PHP as of PHP version 5.3.0 so you don't need 
to explicitly install it.
It's already present in PHP


-- 
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] RFC Proposal: New assign value operator

[Alexey Zakhlestin]

On 26.06.2013, at 17:29, Sebastian Krebs  wrote:

> 2013/6/26 Robert Stoll 
> 
>> As far as I see it, it is kind of an operator overload mechanism for the
>> assign operator.
>> This can be useful for small utility classes such as Money, Email etc.
>> 
>> An example was given:
>> $price = new MoneyValue();
>> $price := 29.99;
>> 
>> Instead of writing something like:
>> $price = new MoneyValue();
>> $price->setPrice(29.99);
>> 
>> The benefit is small, but can lead to better readable code. But since it
>> is only for the assign operator and not for + - etc., for me the question
>> remains open why not writing something like this directly:
>> 
>> $price = new MoneyValue(29.99);
>> 
> 
> You forgot the currency ;) (without it a "money"-type is useless). But this
> leads to
> 
> $price := 29.99;
> $price := 'USD';
> 
> I find it confusing.

Not to mention, that one should NEVER use float for money
http://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency

-- 
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Alexey Zakhlestin]

On 21.02.2013, at 20:08, Levi Morrison  wrote:

>> Personally I would love to see more RFCs focusing on performance and
>> less on syntax changes.
> 
> Some recent tests I performed indicate that JavaScript and Dart are
> both significantly faster than PHP when working with just arrays and
> numbers. If anyone is interested I can provide the test code for more
> scrutiny.  I'd like to see more performance enhancements but I am not
> against other enhancements as well.

That is expected. Both of them use JIT-compilation, which is not present in PHP.
There was some effort to implement PHP in PyPy/RPython, but it is not active
http://morepypy.blogspot.ru/2012/07/hello-everyone.html


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Zend Optimizer+ Source Code now available

[Alexey Zakhlestin]

On Thu, Feb 14, 2013 at 7:21 PM, Zeev Suraski  wrote:

> O+ does perform some optimizations in addition to caching code, in a pretty
> sophisticated manner actually (block optimizations).  Optimizations - which
> can be expensive to carry out - are definitely a good fit with an opcode
> cache, that ensures that you wouldn't have to do these optimizations more
> than once.  I'm obviously subjective but I think the name Optimizer+ does a
> good job at suggesting that it's both an Optimizer but also something else.
> Perhaps we should call it OptiCache? :)
>
>> Questions (I haven't dug through the code):
>>
>>   - What do CLI processes share?
>
> IIRC nothing, presently it's not very useful for CLI except for testing
> (it'll only apply to a single run).  I could be wrong though, Dmitry?

Well, if it does block-level optimizations, that is already enough to
make it useful for CLI-scripts, as even though caching is not relevant
for long-running processes, optimizations should make things faster.

Are optimizations documented?


-- 
Alexey Zakhlestin,
http://github.com/indeyets

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Improved Linux process title support in the CLI SAPI

[Alexey Zakhlestin]

On 07.02.2013, at 16:33, Leigh  wrote:

> Why does this need to be in core? This could just be done as a set of 
> improvements to the existing PECL extension instead. I'd guess that the 
> number of people who require (and would use) this functionality is very very 
> small indeed.

well, 2 reasons:

1. it needs to be injected into main() of php_cli.c
2. it can become a good start for official "CLI" extension. CLI SAPI has 
functionality, which is specific to it and exposing it to userland could be 
useful


-- 
Alexey Zakhlestin
https://github.com/indeyets






--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Improved Linux process title support in the CLI SAPI

[Alexey Zakhlestin]

On 07.02.2013, at 13:54, Leigh  wrote:

> There is a PECL extension that already does something similar. You may want
> to take a look at that.
> 
> http://pecl.php.net/package/proctitle

Did you read RFC?
Keyur mentions it and its limitations there


-- 
Alexey Zakhlestin
https://github.com/indeyets






-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Improved Linux process title support in the CLI SAPI

[Alexey Zakhlestin]

On 07.02.2013, at 9:40, Keyur Govande  wrote:

> Hello,
> 
> I've created a new RFC to improve support for setting a CLI process' title
> on Linux. It is based off of the PostgreSQL implementation and is more
> robust than the proctitle extension.
> 
> More details and patch here: https://wiki.php.net/rfc/cli_process_title

This would be useful for some of my tasks!
I don't like names of functions, but I like functionality and API approach

how about:

bool   cli_title_settable(void);
bool   cli_title_set(string);
string cli_title_get();


-- 
Alexey Zakhlestin
https://github.com/indeyets






-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ZTS - why are you using it?

[Alexey Zakhlestin]

On Tue, Jan 29, 2013 at 1:03 PM, Zeev Suraski  wrote:

> Which brings me to the subject of this mail – why are you using ZTS PHP
> instead of single threaded PHP?  The reasons not to use it are few but
> fairly major – it’s significantly slower than the non-ZTS PHP, and it’s
> significantly less robust in the sense that a single bug somewhere can
> bring down an entire server (or at least a bunch of many different
> threads).  What are your reasons to choose it over FastCGI?

I use it for long-running processes, when I need something like
http://pecl.php.net/package/pthreads
But, those are scenarios, when I don't need bytecode cache, because
everything is preloaded in "real" memory

--
Alexey Zakhlestin,
http://github.com/indeyets

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] array_map() function modification

[Alexey Zakhlestin]

On 12.01.2013, at 21:34, Thomas Hruska  wrote:

> This would allow developers to do things like:
> 
> $keys = array('key1', 'key2', ..., 'keyn');
> $vals = array('val1', 'val2', ..., 'valn');
> 
> $somemap = array_map($keys, $vals);
> 
> Which would result in $somemap containing:
> 
> array('key1' => 'val1', 'key2' => 'val2', ..., 'keyn' => 'valn')

There is a function for this:

http://docs.php.net/array_combine

-- 
Alexey Zakhlestin
https://github.com/indeyets






-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading

[Alexey Zakhlestin]

On 06.01.2013, at 6:38, Stas Malyshev  wrote:

> Following the recent discussion on the list, I've drafted an RFC
> describing the CurlFile solution for it here:
> 
> https://wiki.php.net/rfc/curl-file-upload
> 
> Please review and comment. If there's a general positive feedback, I'll
> try to implement a patch for it pretty soon.

Looks elegant and extensible.
Great work!

-- 
Alexey Zakhlestin
https://github.com/indeyets






-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] release frequency?

[Alexey Zakhlestin]

On 02.01.2013, at 16:33, Johannes Schlüter  wrote:

> 
> 
> Alexey Zakhlestin  wrote:
>> if there's at least one REAL bug fix in release it's worth it
> 
> So, what is a "real" bugfix? Most things are responses on bug reports by 
> users. Form them it is real.

String typos are not "real". Segfault fixes and inconsistent behaviour fixes 
are "real".


-- 
Alexey Zakhlestin
https://github.com/indeyets






--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] release frequency?

[Alexey Zakhlestin]

On 02.01.2013, at 7:26, Stas Malyshev  wrote:

> I see that we do not have a lot of changes in 5.4 since last release. So
> I wonder if it may make sense to reduce release frequency now that we
> got less bugfixes coming in, say from monthly to 1.5 or 2 months between
> release. What do you think?
> 
> Just to be clear, I have no problem (excepting unforeseen circumstances,
> of course) still doing monthly, just not sure it's worth it if we'd have
> less than 10 bugfixes per release…

if there's at least one REAL bug fix in release it's worth it

-- 
Alexey Zakhlestin
https://github.com/indeyets






--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Git Access

[Alexey Zakhlestin]

On 06.12.2012, at 3:38, Sara Golemon  wrote:

> RTFMing is hard, thanks. :)
> 
> remote: Welcome pollita.
> remote: Changesets accepted. Thank you for your contribution.
> remote:
> remote: Attempting to push to mirror g...@github.com:php/php-src.git
> remote: Write failed: Broken pipe
> remote: fatal: The remote end hung up unexpectedly
> To https://git.php.net/push/php-src.git
>   c058ed5..5ac3577  master -> master
> 
> The push to git.php.net succeeded, but its push to github failed.  Is
> there a process that deals with keeping the repos in sync in events
> like this?

I believe it will eventually sync, as "push" propagates all changes, not just 
specific commit


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Alexey Zakhlestin]

I voted "no", "(b)"
We should mention deprecation in manual as hard as possible, we should
mention it in ext/mysql/config.m4 and any other place we can reach.
Then, at some point (I'm fine with 5.6, but 6.0 would do also), we
should just move it to PECL, without using E_DEPRECATED

--
Alexey Zakhlestin,
http://github.com/indeyets

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Generics proposal

[Alexey Zakhlestin]

On 21.10.2012, at 0:59, Nikita  wrote:

> Hello, list. I want to propose generics. 

> So, what you think?

I'm against having this in PHP.

For IDEs, the better solution is to use generics-like syntax in docblocks.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] removing an item from an array

[Alexey Zakhlestin]

On 16.08.2012, at 0:18, Rasmus Schultz  wrote:

> How come there is no straight-foward obvious way to simply remove a given
> value from an array?

Well, this sounds like a reason for creating SplSet class


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions

[Alexey Zakhlestin]

On 24.07.2012, at 15:20, Laruence wrote:

> Hi:
>As the previous threads disscussed,  I make a implemention.
> 
>here is the RFC: https://wiki.php.net/rfc/finally
> 
>any suggestions?

Will it work without "catch" in your implementation?

try {
doSomethingDangerous();
} finally {
doCleanup();
}

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Make try/catch brackets optinal

[Alexey Zakhlestin]

On 20.07.2012, at 12:33, Ivan Enderlin @ Hoa wrote:

> Making braces optional for try/catch does:
> + not break backward compatibility;
> + add consistency in the PHP syntax;
> ± offer a new way to write buggy programs but no more than with other control 
> structures (think about goto ;-)).
> 
> I see more + than - here. Am I wrong?

You are not wrong. This is the inconsistency and it makes sense to fix it.
We are definitely not going to "unfix" it for if/else, so I "+1" your proposal 
in advance


> Moreover, in parallel, a new idea has been landing: introducing the “rescue” 
> keyword as a shortcut/replacement of try/catch, such as:
> $foo = callThatCouldThrow() rescue 'oof';
> Is it possible to chain it, such as:
> $foo = callThatCouldThrow() rescue anotherCallThatCouldThrow() rescue 'oof?';
> 
> Maybe we should start another topic because it could be a nice idea.

I don't see value in this. "finally" would be much more valuable.

try {
doSomething();
} catch (\Exception $e) {
handleException();
} finally {
genericCleanup() // called if everything is good, if everything is bad or 
even if exception is rethrown
}

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Regarding PHP6, string/array APIs

[Alexey Zakhlestin]

Anthony, the whole concept is interesting. Can you probably write that as RFC. 
I believe that will make it easier to read/understand it.

Right now, I have only one question:

On 20.07.2012, at 4:33, Anthony Ferrara wrote:

> The benefit here, is that user types can implement the same "core" interface 
> and be used polymorphically with the core types (for at least the base API). 
> So then, countable() would disappear. 

what is this "core" interface?
something magically assumed for internal types but explicitly defined as 
interface for user classes?
or implicit case-by-case interface like in python?

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Regarding PHP6, string/array APIs

[Alexey Zakhlestin]

On 20.07.2012, at 4:09, Stas Malyshev wrote:

> Hi!
> 
>> 2. It would be really useful to have 2 versions of each function: one
>> which mutates the variable and one which returns the new variable.
>> 
>> Example:
>> 
>> > 'source', $src == 'SoUrCe' $result = lower($srd);   // $result ==
>> true, $src = 'source' ?>
>> 
> 
> I'm not sure I understand why. What's wrong with $src = lowered($src);?

That's just convenience. matter of readability.

lower() can be implemented in userland and if we had "standard" userland 
library that would be a good place for it :)

function lower(&$str)
{
$str = lowered($str);
}

> Also, when lower() returns not true? If there's a legitimate situation
> when it must return not true (I can't think of any, but maybe for more
> complex functions there is) what lowered() is supposed to do in the same
> situation? If there's none, why bother returning true?

As you said, it might be needed in more complex functions and it makes sense to 
return true just for consistency.
Other option is to (implicitly) return null and use exceptions.
And I, personally, would prefer exceptions ;)

>> 3. Speaking of implementation… Functions, which return slice of
>> string/array could be made to reference the same memory-areas as the
>> source strings/arrays. That is until the first modification, of
>> course. Kinda advanced copy-on-write semantics. I know something like
>> that is implemented in D http://dlang.org/d-array-article.html and
>> Go
> 
> Strings are not modified in PHP (IS_STRING zvals can be modified but the
> actual string buffers aren't) so there's no actual "write" and thus no
> copy needed. But having this would require separate refcounting on
> string values, which may be a bit complicated to do.

much worse than that. refcounting on string-slices!

>> 4. casting between strings and arrays of characters would be a great
>> thing to have too. this way, useful array-oriented functions could be
>> applied to strings
> 
> We already have it, it's str_split().

I know. But that is not "casting". I can not pass string to the function which 
expects array (thinking about array_map, array_filter, …). I have to call 
str_split explicitly.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Make try/catch brackets optinal

[Alexey Zakhlestin]

On 19.07.2012, at 13:49, Paul Dragoonis wrote:

> 2) Try with only one line in it to throw an exception doesn't seem
> like a realistic situation.

It could be something like this:

try
$object->method();
catch (\Exception $e)
return false;


and ->method(), obviously, can have quite a long and complex structure

signature.asc
Description: Message signed with OpenPGP using GPGMail

[PHP-DEV] Regarding PHP6, string/array APIs

[Alexey Zakhlestin]

Stas made a good point about need to start with new API, which then can be 
followed by syntactic sugar.

So, we need some ideas to start with:

1. A lot of people told, that it would be a good idea to come with a written 
standard regarding arguments order. I don't care what it will be, as long as it 
will be documented.

2. It would be really useful to have 2 versions of each function: one which 
mutates the variable and one which returns the new variable.

Example:



3. Speaking of implementation… Functions, which return slice of string/array 
could be made to reference the same memory-areas as the source strings/arrays. 
That is until the first modification, of course. Kinda advanced copy-on-write 
semantics. I know something like that is implemented in D 
http://dlang.org/d-array-article.html and Go

4. casting between strings and arrays of characters would be a great thing to 
have too. this way, useful array-oriented functions could be applied to strings

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)

[Alexey Zakhlestin]

On 17.07.2012, at 23:20, Stas Malyshev wrote:

> Hi!
> 
>> That would be: tokenizer + static analysis (with type inference) + replacing 
>> some of the tokens.
>> Not a trivial task, but definitely doable.
> 
> So what would this tool do with this code?
> 
> $a = getFirstArrayName();
> $b = getSecondArrayName();
> $$a = $$b;
> $b[1] = 0;


Something like this:

   $a = getFirstArrayName();
   $b = getSecondArrayName();
   if ($$b instanceof ArrayObject) {
   $$a = clone $$b;
   } else {
   $$a = $$b;
   }

   $b[1] = 0;

> Or this:
> 
> include 'a.inc';
> $a = $b;
> include 'b.inc';
> 
> where a.inc has array $a and b.inc has something like $b[1] = 0; but you
> have no way of knowing it since by the time you run the tool a.inc and
> b.inc are not available to it (think config files).

well, the same as above. not pretty, but that's a safe fallback when type 
inference is not available.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)

[Alexey Zakhlestin]

On 17.07.2012, at 23:01, Stas Malyshev wrote:

> Hi!
> 
>> Options are: * "5-to-6" tool, similar to python's "2-to-3" converter,
>> which will fix code.
> 
> Do you know any practical way of how such tool could work?

That would be: tokenizer + static analysis (with type inference) + replacing 
some of the tokens.
Not a trivial task, but definitely doable.

And a large amount of php code (popular tools, frameworks, …) for writing tests 
:)

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)

[Alexey Zakhlestin]

On 17.07.2012, at 21:50, Stas Malyshev wrote:

> Hi!
> 
>> I am for making array a proper class with methods.
>> 
>> "Legacy" functions can be implemented as wrappers around it:
>> 
>>function array_push(&$array, $value)
>>{
>>$array->push($value);
>>}
> 
> The problem there is that array has different semantics than object. Not
> completely, but for example if you pass array to function, it is passed
> by value and is not modified, but objects are always mutable when passed
> to functions. Changing this semantics will break a lot of code.

Having special handling of Array objects doesn't sound good too. And I don't 
see any nice solution.

Options are:
* "5-to-6" tool, similar to python's "2-to-3" converter, which will fix code.
* introduce some kind of per-file declare() option, which would enable 
pass-by-reference semantics of arrays/strings/etc. in 5.5 which would let 
people write the same code for 5.5 and 6.x

Well, actually, there's one more option: we can introduce "Autocloned" 
interface (empty, without methods) and force "cloning" of objects, which 
implement this interface, during parameter-fetching phase.
This would allow us to have 2 sets of classes: One set which implements this 
interface (slower, but backwards-compatible) and another set which doesn't 
(faster, but not compatible).

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)

[Alexey Zakhlestin]

On 17.07.2012, at 21:03, Stas Malyshev wrote:

> Hi!
> 
>> This idea has been proposed many times in the past and it is actually
>> a very good proposal, for array, string or other types.
> 
> If we have "$array->foo()", we should also have "class foo extends
> array" which allows to override foo() in array. This will require some
> serious changes, which need to be RFCed and reviewed and seen if they
> can really fit the language properly. Just saying "let's bolt on method
> calls on top of arrays" is definitely not very good. Having OO Array
> type may be good, if we will be able to figure out suitable design that
> will allow the same flexibility and power as regular arrays - though I'm
> not sure how to do it now.
> 
>> The only reason why it is not yet implemented is the technical
>> complexity to do it. We need pseudo objects and the likes, and it is
>> really not something easy to do, in an efficient enough way.
> 
> I disagree - I do not think we need pseudo-objects. If the only point of
> the exercise is to convert a call of array_pop to $array->pop, it's not
> worth it. It'd just make the language more messy - you wouldn't know
> what -> means anymore.

+1

I am for making array a proper class with methods.

"Legacy" functions can be implemented as wrappers around it:

function array_push(&$array, $value)
{
$array->push($value);
}

There is absolutely no sense in creating new "pseudo object" entity. It would 
just add tons of confusion.

p.s. in case of array, we already have http://docs.php.net/ArrayObject which is 
a good starting point

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] MYSQL_OPT_RECONNECT

[Alexey Zakhlestin]

On 09.07.2012, at 14:17, Johannes Schlüter wrote:

> an example like this:
> 
>$pdo = new PDO("mysql:...");
>$select = $pdo->prepare("SELECT * FROM t WHERE id = ?");
>/* do something ... connection break in between */
>$delete = $pdo->prepare("DELETE FROM t WHERE id = ?");
>$select->execute([1]);
> 
> This will in fact do a DELETE, not a SELECT as the statement handle
> effectively is nothing but a per-connection counted unsigned long.

Well, this sounds like a bug

Prepared statements should become invalid once connection is lost and further 
attempts to execute them should lead to exception
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding a simple API for secure password hashing?

[Alexey Zakhlestin]

On 18.06.2012, at 19:42, Pierre Joye wrote:

 It is BSD-licensed, so we can easily bundle it with PHP
>>> 
>>> Maybe nice to have in pecl.'
>> 
>> Sure, that's an option, but pecl won't help php to have default 
>> "state-of-art" password hashing toolset ;)
> 
> There is sadly only state-of-art-right-now password hashing methods.
> We have to keep that in mind :)

Sure. but SCrypt is tuneable. One can increase both CPU and RAM complexity and 
CPU complexity is set as function of time.
Which means, that if one upgrades CPU in his server, while leaving settings the 
same complexity will increase automatically.

This feature makes it future-proof to some degree. Well… until quantum 
computers become ubiquitous ;) 
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding a simple API for secure password hashing?

[Alexey Zakhlestin]

On 18.06.2012, at 1:54, Pierre Joye wrote:

>> I guess SCrypt binding could be implemented.
>> http://www.tarsnap.com/scrypt.html
> 
> Using yet another dependency for that? Not good.

That's easier and safer than implementing this on our own.

> 
>> That's the best available option at the moment.
>> http://stackoverflow.com/questions/1226513/whats-the-advantage-of-scrypt-over-bcrypt
> 
> This post says the exact opposite, just saying :)

The post says, that SCrypt is better, because it is way harder to solve.
Bcrypt requires a lot of CPU, but SCrypt requires a lot of CPU + a lot of RAM

>> It is BSD-licensed, so we can easily bundle it with PHP
> 
> Maybe nice to have in pecl.'

Sure, that's an option, but pecl won't help php to have default "state-of-art" 
password hashing toolset ;)


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding a simple API for secure password hashing?

[Alexey Zakhlestin]

On 14.06.2012, at 1:31, Nikita Popov wrote:

> So, wouldn't it be better if PHP provided an easy to use API for
> secure password hashes natively? So you just have to call a single
> function, which magically handles everything for you (like salt
> generation).
> 
> A simple sample API could be two functions password_hash($password)
> and password_hash_verify($password, $hash). But it could just as well
> be a fancy, extensible OOP API.

I guess SCrypt binding could be implemented.
http://www.tarsnap.com/scrypt.html

That's the best available option at the moment.
http://stackoverflow.com/questions/1226513/whats-the-advantage-of-scrypt-over-bcrypt

It is BSD-licensed, so we can easily bundle it with PHP

For the reference, here's the Python binding: 
https://bitbucket.org/mhallin/py-scrypt/src
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Inconsistencies with constructors in SPL

[Alexey Zakhlestin]

On Tue, May 17, 2011 at 4:22 AM, Benjamin Dubois
 wrote:

> Why not make all objects (maybe implicitly) extend a single root object, 
> containing just skeleton ctor/dtor and implemented in the engine ?
>
> I don't know if it is actually  possible in PHP, but that works for several 
> other languages (java, objC - in that case, the root object is explicit-, C# 
> AFAR)
>
> This would also bypass the error-level debate (no error would be thrown)

+1

-- 
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] SplFileObject Countable

[Alexey Zakhlestin]

On Tue, Mar 15, 2011 at 1:54 PM, Nick Pope  wrote:

> Currently we have:
>
>    SplFileInfo  -- information/metadata about a file.
>         |
>         V
>   SplFileObject -- modify/access contents of a file.
>
> It could make sense to subclass this to provide methods for accessing
> information about the contents of a file.  As for a name, I'm not sure what
> would be best, but perhaps something like "SplFileData".  Maybe someone else
> can come up with a better name?

probably SplTextFileObject, as these methods make sense for text files


-- 
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: built-in web server in CLI.

[Alexey Zakhlestin]

On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi  wrote:
> Hi,
>
> Just to let you know that I wrote a RFC about built-in web server
> feature with which PHP can serve contents without a help of web
> servers.  That would be handy for development purpose.
>
> If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .

Interesting, indeed.

I noticed, that you hardcode mimetypes and index_files.
Mimetypes can probably be obtained from the system — we even had some
extension doing that.
And index_files should be configurable, because there are some
situations when people don't want any mime-types at all.

Also, it would be good to be able to configure which files are
actually parsed by php, not just served. Currently, these are only
".php" files

-- 
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Clarification on the Enum language structure

[Alexey Zakhlestin]

On Thu, Feb 24, 2011 at 5:00 AM, Stas Malyshev  wrote:
> Hi!
>
>> You can do it like this. When an enum is defined:
>
> I'm not talking about implementation in the code of PHP engine. I'm talking
> about writing code with these things that wouldn't produce fatal errors in
> random places without you being able to prevent it and without checking
> before each function call. Compiled languages deal with it easily because
> they check these things on compile - if you try to send int variable where
> BlahBlah type is expected, the compiler bails out and you know it's a
> problem. Dynamic languages don't work that way.

except, that it could be handled by "thow new InvalidArgumentException()"
but we don't allow exceptions in core

-- 
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Clarification on the Enum language structure

[Alexey Zakhlestin]

On Wed, Feb 23, 2011 at 4:35 PM, Martin Scotta  wrote:
>  Martin Scotta
>
>
> On Wed, Feb 23, 2011 at 7:12 AM, Ben Schmidt
> wrote:
>
>> Are you suggesting this as an enum member function, or just a regular
>>>> function in any old class?
>>>>
>>>
>>> "Enum member funcion"? How much it should be like a class before you
>>> call it a class?
>>>
>>
>> Exactly. It's crazy. If you want a 'member function' use a class, not an
>> enum.
>>
>
> why not supporting methods for enum values?
> developers will need that, and by providing type hinting, they will just
> create the logic somewhere else...

why would developers need this? can you elaborate with some real-life scenario?
I thought enums are just strong-typed constants


-- 
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Clarification on the Enum language structure

[Alexey Zakhlestin]

On Wed, Feb 23, 2011 at 4:29 AM, Stas Malyshev  wrote:
> Hi!
>
>> public function Killjoy(MyEnum $x)
>
> What would be the purpose of such code? What would it do if 5 is passed as
> $x?

IMHO, it should fail (unless 5 is the value explicitly mentioned in
MyEnum definition)

-- 
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP for embedded device: reduce size

[Alexey Zakhlestin]

On Sat, Feb 19, 2011 at 9:24 PM, Martin Herrman  wrote:
> All,
>
> I have cross-compiled php-cgi for a MIPS device (mediaplayer), but the
> binary is quite large, more than 3MB. I'm using:
>
> ./configure --prefix=../result/php-5.3.5 --host=i686-pc-linux-gnu
> --target=mipsel-linux-gnu --build=mipsel-linux-gnu --enable-cgi
> --disable-all --without-pear --with-config-file-path=/etc/
>
> Which options do I have to reduce size of the binary? E.g. can I
> remove the zend engine?

what do you mean by "remove the zend engine"?
zend engine is the core, upon which php is built.

-- 
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.6RC1 Released for Testing

[Alexey Zakhlestin]

On 17.02.2011, at 16:17, Johannes Schlüter wrote:

> The first release candidates of 5.3.6 was just released for testing and
> can be downloaded here:
> 
> http://downloads.php.net/johannes/php-5.3.6RC1.tar.bz2 (md5sum:
> f78d7b47ddbfca42ebdfcdef2adfe859)
> 
> The windows binaries are available at: http://windows.php.net/qa/
> 
> This is the first step in the release process of this versions and goal
> is having a 2nd RC two weeks from now. Majority of the changes are of
> the "bug fix" variety. To ensure that the release is solid, please test
> this RC against your code base and report any problems that you
> encounter.

Here's the changelog:
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_6RC1/NEWS?revision=308400&view=markup



smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Earliest zend_eval_string can be called?

[Alexey Zakhlestin]

On Sat, Sep 18, 2010 at 1:37 AM, Matthew C. Rice  wrote:
> Hello,
>
>   I was wondering how early a zend_eval_string call can be made. Currently
> it works fine in a PHP_FUNCTION(), but was hoping to put it in a PHP_MINIT()
> in hopes of it just executing once.
>
>   It seems PHP_MINIT() is too early, and is causing failures. I came across
> PHP_GINIT_FUNCTION(), but can't seem to find when its called exactly, but
> the same situation as PHP_MINIT() seems to be the case, where its too early.
>
>   In short, I am wondering if there is any place I can put the
> zend_eval_string() call in hopes of it running just once, so its result
> could be retained throughout the module execution.

definitely, not earlier than PHP_RINIT(), which doesn't help you.
all php's "userland" code is executed in the sandbox and sandbox
exists between PHP_RINIT and PHP_RSHUTDOWN

the only way to execute userland code before serving requests is to
use long running process, which serves requests from userland.
That's what I do in http://github.com/indeyets/appserver-in-php

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Lambdas assigned to constants. Was PHP Annotations RFC + Patch

[Alexey Zakhlestin]

On Thu, Sep 16, 2010 at 10:35 PM, Stas Malyshev  wrote:
> Hi!
>
>> const foo = function () use ($globalVar) {
>>
>> };
>
> How would you call this thing? foo()? Then you have a problem - foo()
> already has meaning, and it's "call function named foo", not "get constant
> named foo and call function inside if it's there".

His idea is, that "get constant named foo and call function inside if
it's there" should be the only meaning
and "function foo() {}" should be syntactic sugar for defining
constant foo with closure inside.

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] #52563: Adding E_NONE and/or E_EVERYTHING constants

[Alexey Zakhlestin]

On Tue, Aug 24, 2010 at 10:14 PM, Stas Malyshev  wrote:
> Hi!
>
>> use an E_ constant with error_reporting" and not have the current
>> situation where sometimes you use a constant (or constants) and
>> sometimes you use a bare number, depending on what you want to
>> achieve.
>
> What's wrong with using 0? 0 means "nothing", how hard is that? `

The only downside is, that programmer will need to know, that E_*
constants do mean numbers.
With adding E_NONE this knowledge would be unnecessary and people
would be able just to think in terms of abstract "symbols"

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] back to 5.4 alpha

[Alexey Zakhlestin]

On Thu, Aug 12, 2010 at 10:59 AM, Lester Caine  wrote:
> Stas Malyshev wrote:
>>>>
>>>> 1. What's missing and should be added?
>>>
>>> First thing perhaps ... which IS Pierre's problem ... Windows snapshots
>>> But short of trawling the commit tree ... what HAS already been added?
>>> ( links to the CURRENT release notes from the windows site are broken
>>> by the way )
>>
>> We have NEWS for this, don't we?
>
> If you are referring to the release notes, yes, I was just pointing out that
> people who are directed to windows.php.net do not get the same level of
> support as Linux users and currently those links are broken.
>
> But the main point was ... where is the NEWS for all the features added to
> trunk? We need the alpha to create the news to decide what needs changing
> before releasing.

http://svn.php.net/viewvc/php/php-src/trunk/NEWS?view=markup


-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] back to 5.4 alpha

[Alexey Zakhlestin]

On Thu, Aug 12, 2010 at 12:28 AM, Lester Caine  wrote:
> Zeev Suraski wrote:
>>
>> You're absolutely right, sorry about that!
>>
>> Zeev
>
> However if this is something controlled by php setup, it becomes another
> 'register_global'. If my users have to have it off for my projects and on
> for others ... complexity in managing instead :(

Nothing is controlled by php setup.
It is perfectly ok to not specify type-hints in your functions.

both of these are fine:

function a($var) {}

function b(int $var) {}


you just keep using syntax of "a" and everything works. you CAN
specify typehint like in "b" but you don't have to.

p.s. if something is still not clear, let's take this talk away from list

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] back to 5.4 alpha

[Alexey Zakhlestin]

On Thu, Aug 12, 2010 at 12:01 AM, Zeev Suraski  wrote:
> At 22:50 11/08/2010, Alexey Zakhlestin wrote:
>>
>> On Wed, Aug 11, 2010 at 11:41 PM, Lester Caine  wrote:
>> > Ilia Alshanetsky wrote:
>> >>
>> >> +1, I think that's the most sensible solution for now that would allow
>> >> us to proceed with 5.4, something we all seem to be in agreement on.
>> >
>> > A slight aside here, as I have not be bothering about what HAS been
>> > implemented typing wise ... A large section of the code a work with
>> > passes a
>> > range of data to functions and classes. If the function gets an integer
>> > it
>> > looks up the record with that id, an array assumes the data is already
>> > loaded, and perhaps a string value defines that a new record of that
>> > name is
>> > to be created. So I don't want the parameters passed to be tied to a
>> > single
>> > type. Is THAT affected by any of the current typing actions?
>>
>> both suggested type-hinting strategies are optional.
>> so, you, as developer, are free to not use type-hinting and accept any
>> data you like
>
> Alexey,
>
> It's been explained countless times why this is WRONG.
> Please read the archives.
> If you have and you disagree with it, please take it as an axiom - a feature
> being 'optional' does not take away from any confusion or complexity
> associated with it.  It's been a design guideline in PHP from the get go,
> we're not going to give up on it now.

You misunderstood my comment.

Lester asked if he can still have his APIs without type-hinting and I
told him that he can.
That's all

We're not talking about complexities of understanding

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] back to 5.4 alpha

[Alexey Zakhlestin]

On Wed, Aug 11, 2010 at 11:41 PM, Lester Caine  wrote:
> Ilia Alshanetsky wrote:
>>
>> +1, I think that's the most sensible solution for now that would allow
>> us to proceed with 5.4, something we all seem to be in agreement on.
>
> A slight aside here, as I have not be bothering about what HAS been
> implemented typing wise ... A large section of the code a work with passes a
> range of data to functions and classes. If the function gets an integer it
> looks up the record with that id, an array assumes the data is already
> loaded, and perhaps a string value defines that a new record of that name is
> to be created. So I don't want the parameters passed to be tied to a single
> type. Is THAT affected by any of the current typing actions?

both suggested type-hinting strategies are optional.
so, you, as developer, are free to not use type-hinting and accept any
data you like

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Strict typing

[Alexey Zakhlestin]

On Wed, Aug 11, 2010 at 8:56 PM, Josh Davis  wrote:
> On 11 August 2010 08:23, Stas Malyshev  wrote:
>
>>> I very much can, it's just not my intention. I want to be able to use
>>> type hinting/type checking as a sanity check. If I write a method
>>> whose signature is foo(int $n) I signal my intention to only accept
>>
>> Then you should use statically typed language.
>
> Yeah, hmm, no, and it is disingenuous of you to equate type hints to
> PHP becoming statically typed. I'm sure that some people would love to
> have optional static typing in parts of their code, but I like being
> able to use my vars freely when I need to. Being able to enforce what
> type of arguments can be passed to my functions and methods would
> allow me to cut down on my parameters validation. Similarly, I like
> using protected methods to prevent users [developers using the code]
> from misusing them or protected properties to prevent users from
> inadvertently modifying them, so that I don't have to worry about the
> application being in an inconsistent state.
>
> PHP being dynamically typed shouldn't be an argument to prevent people
> from enforcing method signatures. You're saying that PHP users should
> have no control over what variable types are passed to their
> functions.

Did you read second RFC? The one which is about "so called" weak typehinting.
Stas (and a lot of people on this list) prefer it.
http://wiki.php.net/rfc/typecheckingstrictandweak

If you did, can you tell if there is some case, when it doesn't work for you?

The idea is simple:
1) if variable type matches — variable is passed to function
2) if variable can be safely converted to the type, which matches —
variable is converted and passed to the function (you still get
variable of desired type)
3) if variable can not be safely converted — error is raised

error is E_STRICT or E_FATAL (not decided yet). anyway, you can handle
it as fatal in error-handler if you need to

this way you (library developer) get your desired data-types for input
and users get freedom to pass numeric strings instead of numbers
good for everyone

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Strict typing

[Alexey Zakhlestin]

2010/8/11 Ryan Panning :

> Because the current syntax used for type hinting
> classes/arrays is strict. If changed, you would need to specify that scaler
> types are weak but classnames are strict and now you have a WTH moment.

Not really. Class type-hinting is not strict. The only reason why it
looks strict is, that PHP doesn't provide userland ways for
object-casting.
As far as I remember, zend-engine, underneath, actually has hook for
casting. And nothing stops us from supporting such casting with hints,
eventually.

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bugs assigned to cellog

[Alexey Zakhlestin]

On 01.07.2010, at 1:24, Gregory Beaver wrote:

> Hi,
> 
> I will be unable to fix even the smallest bugs assigned to me, it
> would of great assistance if a developer who has both time and a
> reliable Internet connection would step in and fix them.  The
> phar.phar bug should be easy.  The tar/zip difference needs a sample
> zip that does not work and the others I don't know about.  I would be
> happy to fix them under ordinary circumstances, but I have no free
> time (my daughter just started walking) and will only have Internet
> through my phone until mid-August.  Php development on a phone is nor
> possible yet :)

You just have a wrong phone :-P
Anyway, my congratulations on your new project :)

I'll take a look at that "zip" bug. Bumped into it myself, so have some 
personal interest.




-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/






smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Performance problem with php

[Alexey Zakhlestin]

On 20.06.2010, at 10:49, Vincenzo D'Amore wrote:

> Hello,
> 
> to have a performance problem with apache/mod_php5 configuration under heavy
> load the website becomes too slow.
> Using strace I found what appears to me a strange behavior
> The strange behavior I want point out is related to a sequence of tentative
> httpd/mod_php5 does in order to read an php page.

let's start with the basics.

what version of php is this?
what version of apache (and which mpm) is this?
what OS is this?

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/






smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver

[Alexey Zakhlestin]

On 14.06.2010, at 11:28, Ferenc Kovacs wrote:

> quoting Denis:
> 
> "Actually all the methods are wrappers against the native PostgreSQL
> commands (connection status, copy to/from).
> 
> I needed to develop them as methods because it is not possible to get the
> same results with a sql statement (in particular for connection status).
> 
> It was not possible also for COPY TO/FROM because of the way PostgreSQL
> handle them ( special functions were developed also for the old pgsql
> driver)."
> 
> I don't know sqlite or IBM, but the MySQL SELECT INTO OUTFILE is a plain SQL
> statement, you don't need any special pdo function to use it, on the other
> hand, you can't use the postgresql's COPY TO/FROM with PDO without the patch
> above.
> Did I misunderstood something?

well, even if it's possible to do as "sql" in mysql, it is still possible to 
implement as the method.

p.s. actually, as we're talking about "trunk" it is still possible to implement 
these methods in generic fashion.
I can provide implementation for pdo_mysql (unless anyone else will be faster).
does anyone know enough about ibm's api to provide implementation for it?


-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/






smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver

[Alexey Zakhlestin]

On 12.06.2010, at 15:54, Ilia Alshanetsky wrote:

> The concerns you raised about custom methods specific to database drivers
> were not reflective of the PDO's intent as was clarified by Wez and myself.
> 
> The code that was introduced was specific to PostgreSQL, the common
> functionality was introduced in a way that allows each driver to implement.

I agree with Ilia on this.
Piece of functionality which is "common" was implemented in generic way. Piece 
of functionality which is not "common" was implemented as postgresql-specific 
extension.
That's exactly how it should be and the fact of updates to PDO is awesome on 
it's own.


> On Sat, Jun 12, 2010 at 12:24 PM, Pierre Joye  wrote:
> 
>> hi Ilia,
>> 
>> So you basically say that the worries and wishes raised here are
>> simply irrelevant and at the end of the day you decide what PDO can or
>> cannot be?
>> 
>> I'm very disappointed by these two commits. I don't think it is the
>> way we should develop PDO and it is clear that I'm not the only one to
>> think that. As it is trunk, I won't battle too much to revert it but
>> be sure that is not something I will let in for any of the upcoming
>> releases as it is clearly bad design.
>> 
>> Cheers,
>> --
>> Pierre


-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/






smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Proper return after throwing exception

[Alexey Zakhlestin]

On 10.06.2010, at 23:41, Pieter de Zwart wrote:

> Hey guys,
> 
> Another n00b question: What is the proper way to return from a function
> after throwing an exception? My code looks like:
> 
> zend_throw_exception(amqp_connection_exception_class_entry, "blah blah
> blah", 0 TSRMLS_CC);
> return; 
> 
> Should I instead RETURN_FALSE from there?

It doesn't really matter, as return value will never be checked.
"return" should be enough


-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/






smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver

[Alexey Zakhlestin]

On 24.05.2010, at 22:04, Pierre Joye wrote:

> hi Ilia,
> 
> On Mon, May 24, 2010 at 7:53 PM, Ilia Alshanetsky  wrote:
>> since when? PDO was designed to allow drivers to provide their own
>> functions, which many drivers do.
> 
> We discussed that on the PDO list, and we try to avoid to add drivers
> specific methods. That's obviously makes sense given the goal of PDO.

Well, if driver provides some unique functionality, which can't be implemented 
any other way, I'd say, that it should be implemented.
If there is a way, to make this functionality generic, it should be generic.

Limiting ourselves to Least Common Denominator is not the best idea.


-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/






smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] PHP 5 X PHP 6

[Alexey Zakhlestin]

On 18.05.2010, at 19:33, Mathias Grimm wrote:

> Is the http://wiki.php.net/rfc for both php5 and php6?
> 
> there are differents developer teams for dev 5 and 6 ?
> 
> When something new comes to php 5, php 6 must implement it to?

At the moment, there is no such thing as "php 5"

there is php5.3 and there is "trunk"

trunk includes all changes from php5.3 and some more


-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/






smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Re: Turkish/Azeri locale support

[Alexey Zakhlestin]

On 04.05.2010, at 16:44, Steven Van Poeck wrote:

> Adam Harvey wrote:
>> Well, I'm going to assume that people have had whatever say they were
>> going to. It seems that we have three options, so let's put it to a
>> vote.
>> 
>> (To be completely clear, this is purely for trunk. This certainly
>> isn't a candidate for backporting to 5.3.)
>> 
>> The options are:
>> 
>> 1. Apply Tomas's patch to make case-insensitive lookups
>> locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for
>> case-insensitive function/method name lookups for high-bit characters
>> in single-byte encodings. (Not that we've ever advertised or
>> documented that.)
>> 
>> 2. Make function/method names case-sensitive, per Stan's e-mail. Pros:
>> fixes problem; brings PHP into line with most other languages; extra
>> consistency with variables; possible performance improvement. Cons: BC
>> break from current documented behaviour.
>> 
>> 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to
>> annoy Turkish and Azeri developers and those developing for those
>> locales.
>> 
>> If you'd care to reply with a vote for option 1, 2 or 3, I'll tally up
>> the votes in a week or so. And yes, I am volunteering to deal with
>> this should option 1 or 2 be picked.

my vote: option 2

that's the most consistent solution

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Debugging a PHP Extension via GDB

[Alexey Zakhlestin]

On 22.04.2010, at 17:51, Sebastian Kurfürst wrote:

> Hello everybody,
> 
> [I hope this is the right list for this question, if not, it'd be great
> if you could point me to the right direction].
> 
> I'm currently developing a PHP Extension which is built as dynamic
> library, and not directly into PHP core. I'm trying to figure out how to
> set break-points inside the extension with GDB, so debugging is easier.
> 
> So far, I started gdb with "gdb /my/path/to/php" (which has debug
> symbols enabled); and then tried to set a breakpoint into my extension via:
> 
> break /path/to/php/extension/objectmonitor/objectmonitor.c:80
> 
> GDB then asks:
> 
> No source file named /path/to/php/extension/objectmonitor/objectmonitor.c.
> Make breakpoint pending on future shared library load? (y or [n]) y
> 
> When I run php with a script via "run index.php", the system does not
> stop at the set break-point.
> 
> Do you have any hints how to make this work? This really would help me
> tremendously.

Do you use debug-build of PHP? There won't be symbols in "regular" build
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] php 5.3, memory leak

[Alexey Zakhlestin]

I was doing some tests with long-running scripts recently and noticed that 5.3 
is leaking memory in cases where 5.2 wasn't.
Looks like there is bug report already: http://bugs.php.net/bug.php?id=48781

PHP 5.3 was announced as more suitable for long-running scripts than 5.2 was, 
because of circular-references garbage collector.
But this bug undermines this. So, I believe this bug is a critical one. Should 
be a blocker for 5.3.3

Bug-report tells that this bug was assigned to Dmitry, but, as there were not 
comments from him, I am not even sure if he's actually aware of the problem.

Did anyone try to investigate the issue?

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Supplying nothing at all for default parameters

[Alexey Zakhlestin]

On 06.04.2010, at 14:16, Richard Quadling wrote:

> Hello.
> 
> A suggestion I would like to make is to allow for nothing to be
> supplied for defaulted parameters.
> 
> I suppose the easiest way of describing this issue is with the
> following code ...
> 
>  function foo($bar, $baz = 9, $buzz = 10) {
> return "$bar $baz $buzz";
> }
> 
> // Whatever is supplied for $baz will be used for $baz.
> // User has to know the default value of $baz rather than just
> allowing the default value.
> echo foo(1, 9, 20);
> 
> I don't know the stylics on using default parameters, but for the user
> to have to know the default value would sort of make the default
> redundant.
> 
> 
> // Passing nothing at all could be one option.
> echo foo(1, , 20);
> 
> but who would want to see ...
> 
> echo anotherfoo(1, , , , , , , 20);
> 
> for example.
> 
> 
> Maybe a new keyword ... (ala SQL syntax).
> 
> echo foo(1, default, 20);

another solutions is to use named parameters as suggested in one of the recent 
discussions.
named parameters allow you to specify only those parameters which you need and 
not care about order of parameters

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] php and multithreading (additional arguments)

[Alexey Zakhlestin]

On 05.04.2010, at 13:46, Moriyoshi Koizumi wrote:

> I used to play with TSRM days ago and successfully implemented
> userland threading support using GNU Pth.  It's just a proof of
> concept and I did it for fun.

So these are share-nothing worker-threads, which can send results to 
"master-thread" using messages. right?
I am perfectly fine with such approach

some stylistic moments:
* I would use closures instead of callback-functions
* Is extra language construct really needed? function-call would work just fine

Is overhead of starting new thread large?


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] unsigned chars

[Alexey Zakhlestin]

Use "reply all" when writing to mailing-list.


On 05.04.2010, at 13:18, donald sullivan wrote:

> what i am trying to do is RSA encryption
> 
> I have a working setup doing encryption and decryption at the same time. i 
> want to store the encrypted value and be able to decrypted it later
> 
> if i encrypt the data and send the data straight to the decrypt function it 
> works fine
> 
> int decryptRetVal = RSA_public_decrypt(512, Buffer, plainText, rsaPubKey, 
> RSA_PKCS1_PADDING);
> 
> if i try to send the output of the encryption to the php side for storage, or 
> even write it to a file and then read that file for decryption it fails every 
> time
> 
> int decryptRetVal = RSA_public_decrypt(512, (unsigned char *)Z_STRVAL(zret), 
> plainText, rsaPubKey, RSA_PKCS1_PADDING);
> 
> how can i store the encrypted output for later use?

well, it should work
you don't give details, so I can't say what are you doing wrong.

I can give you only generic debugging advices:
make sure that the data you store on php-side is equivalent to the data you 
expect to get on C-level.
If it is not — try to locate the step which corrupts the data, etc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] unsigned chars

[Alexey Zakhlestin]

On 05.04.2010, at 13:01, donald sullivan wrote:

> is it possible to return unsigned chars from an extension?
> I have looked and cant find anything on it, or maybe i am looking for the 
> wrong keywords.

Return to PHP-code?

No. PHP doesn't have explicitly signed or unsigned chars. PHP has "strings"
you can return:
1) string of chars
2) int (array of ints?)

Also, see http://docs.php.net/ord
ord() function converts first byte of byte-string to it's unsigned numeric 
representation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php and multithreading (additional arguments)

[Alexey Zakhlestin]

On 01.04.2010, at 22:38, Stanislav Malyshev wrote:

> Hi!
> 
>>   processing, but then the state syncing of the forked background 
>> processing
>>   results with the main thread requires a whole new protocol / switching 
>> to
>>   interprocess communication, which makes such developments unnecessarily
>>   hard. Threads exist for a _reason_ not only because they sound cool.
> 
> Interesting thing here threads would require (at least if they are 
> implemented the way C, etc. threads usually work) whole new protocol of 
> synchronization too. Just think about something: do you have shared 
> classes/variables/etc.?
> If you do, how you control access to them? Hello locks and the whole can of 
> worms! Most people that think they can program in threads actually are just 
> pushing their luck until some complex interaction leaves their app 
> malfunctioning in a bizarre way and them without any means to debug it. I 
> mean, you can do it right, but it's usually harder than it looks. 
> Share-nothing exists for a reason too :)

Well, strictly speaking, there are [at least] 2 models which can be used:
1) Classical with shared resources and locking
2) STM

Anyway, do we really have to tell people "you don't need it" when they believe 
that they do?
Python has multithreading and it works reasonably good. People who know what 
they are doing can implement really brilliant solutions (think Tornado)
And something like GIL feels like a reasonable compromise to me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] How to trace a crash bug?

[Alexey Zakhlestin]

On 27.03.2010, at 9:05, Thomas Hruska wrote:

> One thought:  Has a way to track call depth been considered (perhaps 
> _execute())?  If the number of calls exceeds a certain (reasonable) number, a 
> warning or notice could be displayed and the output buffer flushed.  That 
> way, when it crashes, there is a log of some sort for the function.  Then 
> again, I don't know Zend well enough to make that sort of judgment call and 
> such a thing could affect performance.

XDebug can do this.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DTrace RFC

[Alexey Zakhlestin]

On 25.03.2010, at 13:24, David Soria Parra wrote:

> Hi,
> 
> I would like to backport the DTrace patches that were committet to the
> latest trunk. This is related to RFC http://wiki.php.net/rfc/dtrace
> . If there are no objections I'll commit this within the next weeks.
> As DTrace doesn't break BC I think it should be a big deal.
> 
> objections?

no objections from me.
should be committed :)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] FPM RFC

[Alexey Zakhlestin]

On 24.03.2010, at 0:58, Antony Dovgal wrote:

> On 24.03.2010 00:05, Zeev Suraski wrote:
>>> How do you propose to describe the same set of options using php.ini syntax?
>>> Yes, simple things like "value=Yes/No" or "value=DIR" fit just fine 
>>> into php.ini.
>>> But how would decribe a set of pools each with its own set of options?
>>> (taking into account that some of these options may override global options)
>> 
>> option...
>> anotheroption...
>> 
>> [pool1]
>> option...
>> anotheroption...
>> 
>> [pool2]
>> option...
>> anotheroption...
> 
> Okay, here is XML based config quickly converted to php.ini-style syntax:
> 
> I won't discuss how it looks to me, but there is only one problem: it doesn't 
> work. 
> That's because php.ini doesn't support nested sections and without them it 
> turns into a real mess.

looks almost like YAML ;)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.4 branch and trunk

[Alexey Zakhlestin]

On Tue, Mar 16, 2010 at 6:58 PM, Derick Rethans  wrote:

> Right now, there are the following features that I can see we should
> think about:
>
> - the new output buffering mechanism (I can not really see why we would
>  not want this)
> - Scott's big number improvements. Scott, can you explain (in an RFC)
>  what exactly this does and how it works?
> - Ilia's scalar type hint patch. There are RFCs:
>  http://wiki.php.net/rfc/typechecking
> - traits, there are also RFCs:
>  http://wiki.php.net/rfc/horizontalreuse
>  http://wiki.php.net/rfc/nonbreakabletraits

+ merge php-fpm branch?



-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] XML binding & mapping library

[Alexey Zakhlestin]

On 16.03.2010, at 10:46, John wrote:

> Hello, people. I am looking for community feedback about my 
> ideas for XML binding & persistence library:
> 

Are you thinking about implementing it as some kind of extension? or about 
php-code?
or just reusable C-library with bindings for PHP?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

[Alexey Zakhlestin]

On 14.03.2010, at 17:43, dreamcat four wrote:

> You should implement UTF-8, with a view to still allow adding UTF-16
> support later on. That is to say, the encoding should be wrapped, and
> switchable underneath. Of course all that is easier said than done
> with PHP. But thats the right way to do it.

I think you misunderstand and probably there are others too…
The discussion is not about which encodings should be supported and which 
should not. PHP6 in its current form supports pretty much all encodings there 
are. The discussion is about which encoding should be taken as "internal 
representation". Currently, PHP6 uses UTF-16 for this purpose.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Tests repository

[Alexey Zakhlestin]

On 12.03.2010, at 22:23, Pierre Joye wrote:

> On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin  wrote:
>> 
>> On 12.03.2010, at 22:06, Pierre Joye wrote:
>> 
>>> Many tests fail because they are written for a given platform, or even
>>> worst (from a portability point of view), only for a given
>>> configuration (library version, system version,etc.). And that's not
>>> about windows vs other, tests can work on a Debian/ubuntu version and
>>> fail on another.
>> 
>> Well, these tests should just be removed/rewritten.
>> Php-tests should test php, not libraries
> 
> I would be interested to know how can we test the file API without
> testing libc, for example.

see my reply to Stas.

The idea is to test things which we can guarantee. If our documentation says, 
that function does this or that, then we should check for it and wrap 
system-calls in such way, that our "file API" always does these things or fails 
in strict predictable manner.
And if we can't guarantee some behaviour then we should add corresponding note 
to documentation and we shouldn't add tests.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Tests repository

[Alexey Zakhlestin]

On 12.03.2010, at 22:20, Stanislav Malyshev wrote:

> Hi!
> 
>> Well, these tests should just be removed/rewritten.
>> Php-tests should test php, not libraries
> 
> That's easy to say - but how exactly you're going to test functionality of, 
> say. ext/intl without testing the underlying ICU library?

Well, here's the way I see it:

Extensions (including ext/intl) declare their API and tests are made againt 
this API. No more and no less.

If, for example, some error-text comes directly from underlying library and 
extension doesn't have control over it it shouldn't be part of API.
In this case we can test that "some error-text was returned" but we shouldn't 
test for exact text-match
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Tests repository

[Alexey Zakhlestin]

On 12.03.2010, at 22:06, Pierre Joye wrote:

> Many tests fail because they are written for a given platform, or even
> worst (from a portability point of view), only for a given
> configuration (library version, system version,etc.). And that's not
> about windows vs other, tests can work on a Debian/ubuntu version and
> fail on another.

Well, these tests should just be removed/rewritten.
Php-tests should test php, not libraries

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] variables in namespaces, was: On closures and lamdba

[Alexey Zakhlestin]

On 24.02.2010, at 15:11, Alain Williams wrote:

> On Wed, Feb 24, 2010 at 02:20:38PM +0300, Alexey Zakhlestin wrote:
>> 
>> On 24.02.2010, at 13:28, Alain Williams wrote:
> 
>>> Objects are not always the answer.
>> 
>> in situation, which you described, objects are definitely the answer.
>> you have several functions, which share the same "state". that's very close 
>> to the definition of object.
> 
> Maybe 'private static' -- ie shared between different objects.
> It is not always appropriate, eg a generic logging function, called from all 
> over
> the place - it is not always convenient to pass a logging object around;
> you just want to call the logging function.

this one is solved by singleton ;)
gives real protection for "private" var as a bonus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] variables in namespaces, was: On closures and lamdba

[Alexey Zakhlestin]

On 24.02.2010, at 13:28, Alain Williams wrote:

> On Tue, Feb 23, 2010 at 11:01:05PM -0800, Stanislav Malyshev wrote:
>> Hi!
>> 
>>> I never did understand *why* variables were not namespaced.
>> 
>> If you have so many global vars you need to namespace them, you should 
>> not use global vars.
> 
> It is not a question of number -- you may have some module where the
> functions need to share a couple of variables between themselves, eg a file 
> handle.
> If variables could be private to a namespace then you would be confident that
> you would not get a variable name collision with some other, independently 
> developed,
> module.
> 
> Objects are not always the answer.

in situation, which you described, objects are definitely the answer.
you have several functions, which share the same "state". that's very close to 
the definition of object.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.

[Alexey Zakhlestin]

On 31.01.2010, at 9:11, Richard Lynch wrote:

> I have taken the liberty of making an RFC for this:
> http://wiki.php.net/rfc/url_dots

thanks. looks good to me

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/NEWS branches/PHP_5_2/ext/pcre/pcrelib/AUTHORS branches/PHP_5_2/ext/pcre/pcrelib/ChangeLog branches/PHP_5_2/ext/pcre/pcrelib/HACKING bra

[Alexey Zakhlestin]

On 29.01.2010, at 13:32, Pierre Joye wrote:

> On Fri, Jan 29, 2010 at 9:36 AM, Alexey Zakhlestin  wrote:
>> As far as I remember, it was decided that C99 is ok for php6.
> 
> I can't remember any decision about C99.

I remember some talk with andrei on irc… I guess we never wrote that down

> 
>> Anyway, we probably need to compose some table on what compilers have 
>> limited (and how limited) support for c99.
>> Then we can objectively decide if we can leave those aside
> 
> That's not a solution, or we kill solaris, HPUX, windows, etc.
> support. GCC does a very bad job here by enabling part of C99 by
> default and breaking the other half of the specs. Also C99 is pretty
> much a bastarized version of C++ in an incompatible way. The price to
> accept C99 is too high, especially when all we use (in 99.9% of
> what the usages) is stdint/stdbool.
> 
> Simply detect and define them at configure time will kill the need to
> use c99 and keeps us on the good/right side (what I do on win for
> example,easy) :)

you forgot about C++-style comments :)
Does Visual Studio support none of C99? I thought recent versions had partial 
support
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/NEWS branches/PHP_5_2/ext/pcre/pcrelib/AUTHORS branches/PHP_5_2/ext/pcre/pcrelib/ChangeLog branches/PHP_5_2/ext/pcre/pcrelib/HACKING bra

[Alexey Zakhlestin]

On 29.01.2010, at 1:39, David Soria Parra wrote:

> On 2010-01-22, Johannes Schlüter  wrote:
>> Hi,
>> 
>> On Thu, 2010-01-21 at 17:49 +, Ilia Alshanetsky wrote:
>>> iliaaThu, 21 Jan 2010 17:49:38 +
>>> 
>>> Revision: http://svn.php.net/viewvc?view=revision&revision=293812
>>> 
>>> Log:
>>> Upgraded bundled PCRE to version 8.01
>> 
>> This seems to depend on some parts of C99, at least stdint.h, by that it
>> breaks the build for some compilers.
>> 
> 
> Yes I have the same opinion as johannes. We should decide if we want C99 or 
> not,
> and then use the appropriate compiler flags. At the moment we depend on lazy 
> compilers and libc's that allow you to include c99 stuff without telling the
> compiler to use c99. As Johannes already said, this breaks PHP for some
> compilers and some libc's.

As far as I remember, it was decided that C99 is ok for php6.

Anyway, we probably need to compose some table on what compilers have limited 
(and how limited) support for c99.
Then we can objectively decide if we can leave those aside

Probably we can decide on limited subset of C99, which is ok to use.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.

[Alexey Zakhlestin]

On 21.01.2010, at 18:21, Richard Lynch wrote:
> 
> For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet
> another php.ini flag (sorry!) to choose the behaviour.

-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a major 
release, after all.

It would be absolutely enough to add optional var-name conversion to extract()
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] function call chaining

[Alexey Zakhlestin]

On 19.01.2010, at 13:47, Christian Schneider wrote:

> Alexey Zakhlestin wrote:
>> Would be nice if something like this worked too:
>>(new Class())->method();
> 
> If you *really* want to do this you can use a factory method:
> Class::create()->method();

I know. That's what I do if I need it.
Or just create temporary variable

But, still, I want consistent syntax, which doesn't put limitations on me
this construct is an example of things, which many people take for granted and 
are shocked, when they discover, that they can't use it.
I saw a lot of questions on forums regarding it
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] function call chaining

[Alexey Zakhlestin]

On 19.01.2010, at 3:27, Stanislav Malyshev wrote:

> Hi!
> 
> I wrote a small patch that enables this kind of syntax in PHP:
> 
> foo()();
> 
> What it means is that if foo() returns callable value (which probably should 
> be function name or closure) then it would be called. Parameters and more 
> than two sets of () work too.
> Of course, this is mostly useful for doing closures, and that was primary 
> drive for implementing it - to make working with closures and especially 
> function returning closures easier.
> What does not work currently is $foo->bar()() - since it is surprisingly hard 
> to tell parser it's not {$foo->bar}()() - which of course is not what I want 
> to do.

I like it!

regarding $foo->bar()()…
is it possible to use precedence rules here? something like:

($foo->bar())();


> What do you think? If somebody has better idea btw - maybe make something 
> like {foo()}() - and make that work for any expression inside {} - that might 
> work too. So, what do you think?

why curly braces?
Parentheses would feel more natural here.

Would be nice if something like this worked too:

(new Class())->method();


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php