Re: [PHP-DEV] [VOTE] Fiber API

[S.A.N]

Maybe someone can help in the finalization Fiber.
Haitao Lv, in pull request asked for help from Dmitry Stogov and
Nikita Popov, but no one answered him.
https://github.com/php/php-src/pull/3203

All popular web programming languages (JavaScript, Python, Ruby, Lua,
etc..) already implement userland async runtime.

Thanks.

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

Re: [PHP-DEV] Re: [RFC] Fiber support (again)

[S.A.N]

Fiber and all async functions, without event-loop - useless.
Need new PHP Application Server.
Best variant `libuv` in core PHP for event-loop and async I/O, and
implementing as async PHP SAPI as `Nginx Unit` module
http://unit.nginx.org/

Thanks.

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

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[S.A.N]

If you implement scalar objects:
https://github.com/nikic/scalar_objects

Then 80% of global functions (array_*, str_*) will be localized using
scalar object methods ($array->split(), $string->join()) and the PHP
developer's response will be positive.

Thanks.

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

Re: [PHP-DEV] [RFC] Fiber support (again)

[S.A.N]

This has already been discussed in github

Fiber::resume()
https://github.com/fiberphp/fiber-ext/issues/7

Fiber::throw()
https://github.com/fiberphp/fiber-ext/issues/6

Keywords - async/await
https://github.com/fiberphp/fiber-ext/issues/10

I believe that current API is normal for the Pecl ext, but to become
semantics of PHP language, the API needs to be improved

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

Re: [PHP-DEV] GD vs Imagick

[S.A.N]

2017-08-15 13:52 GMT+03:00 Rasmus Schultz :
> The following GD issue is all-too common:
>
> https://stackoverflow.com/questions/5773032/how-to-stop-gd2-from-washing-away-the-colors-upon-resizing-images
>
> Basically anyone who's ever accepted uploaded images and resized or
> converted them, has bumped into this.
>
> Only Imagick makes it possible to work around this issue, it's not possible
> with GD, at all - and the internal behavior of GD is arguably "wrong", as
> the visible output of simply opening and saving a JPEG image with GD is
> mangled with washed-out colors.
>
> I am starting to wonder why GD is the default in PHP?
>
> It's a pretty outdated library with a clunky API - we have Imagick with a
> much more concise API and a ton more useful features.
>
> Why is the less-capable image library the default on the PHP platform? Why
> not Imagick?

Imagick - unsafe, slow and requires many external dependencies.

Now there are much better modules:
Vips - safe, much faster (7x) requires little dependency.
http://pecl.php.net/package/vips

It's better to spend your time on Vips , instead of having an Imagick
Thank.

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

Re: [PHP-DEV] Binary (msgpack) serialize/unserialize

[S.A.N]

2017-06-29 2:13 GMT+03:00 Stanislav Malyshev :
> Hi!
>
>> Back in 2014 there was an informal proposal on the mailing list to replace
>> PHP serialization with an efficient binary (msgpack) format.
>
> Why replace? If you have it as an extension, can't people that want to
> use it just use it?
>
> I'm still not sure why we need to do anything in core that can't be done
> in an extension. Is there some handler missing that doesn't allow to use
> custom serializer in some scenario?

PHP Session, Memcache, Redis, etc - not configuring custom serializer.

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

Re: [PHP-DEV] the experimental jit-branch is impressive

[S.A.N]

> 7.1.5 PGO: Requests per second: 886.63
> 7.2.0 JIT PGO: Requests per second: 925.96
>
> OK, than it are "only" 5% on a highly optimized codebase

Try PHP script as daemon mode, will speed up 2x

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

Re: [PHP-DEV] Directory separators on Windows

[S.A.N]

> +1
> Can be used, for convert NAMESPACE to filepath in autoload )
>
> 
> function __autoload($path)
> {
> include convert_seperators($path);
> }
>
>
> On Windows, it is what realpath does.
>

No, realpath() - is not used `include_path`

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

Re: [PHP-DEV] Directory separators on Windows

[S.A.N]

> Another option would be to create a function that converts all slashes in a
> given input string to whatever the directory seperator should be on that
> platform.  This way, devs wouldn't have to deal with bulky aliases like
> DIRECTORY_SEPERATOR cluttering up their code.
>
> For example:
>
> 
> print convert_seperators( '/some\directory/' );
>
> ?>
>
> The above would output "/some/directory" on Linux and "\some\directory" on
> Windows.

+1
Can be used, for convert NAMESPACE to filepath in autoload )

http://www.php.net/unsub.php

Re: [PHP-DEV] JIT for PHP project

[S.A.N]

> The project is in the very early development stage.
>
> Now, JIT passes almost all PHPT tests, makes 3 times speed-up on bench.php 
> and no significant difference on real-life apps (+/-5% depended on 
> opcache.jit setting.
>

Have you tried to measure in frameworks as PHP script daemon, such as
Amp, ReactPhp, etc...?
Perhaps there will be two-fold increase in performance.
If yes, then this is a good argument to implement in PHP 8, native
application  server, like Express in Node.js?

Thank.

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

Re: [PHP-DEV] JIT for PHP project

[S.A.N]

Is planned async/await and native event-loop (maybe libuv)?

Thank.

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

Re: [PHP-DEV] RFC - Immutable classes

[S.A.N]

May be better to do as immutable arrays?

const EmailObject = new Email;

It will be a super global immutable instance of Email.

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

Re: [PHP-DEV] RFC - Immutable classes

[S.A.N]

May be better to do as immutable arrays?

const = new Email;

it will be a super global immutable instance of Email.

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

Re: [PHP-DEV] Exception::getLine()

[S.A.N]

+1

There is use case - exception without backtrace, used to global return.

Example REST API
throw new RedirectExeception('/url', 302); // creating in backtrace is overhead

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

Re: [PHP-DEV] Implement Generator::__invoke($value) as alias to Generator::send($value)

[S.A.N]

2016-05-20 17:41 GMT+03:00 Niklas Keller <m...@kelunik.com>:
> 2016-05-20 15:34 GMT+02:00 S.A.N <ua.san.a...@gmail.com>:
>>
>> Many interfaces work with callback functions, but they might work with
>> the generators, if there was a method Generator::__invoke($value).
>
>
> You can just use [$generator, "send"].
>

Yes, but it is slow and not nice :)

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

[PHP-DEV] Implement Generator::__invoke($value) as alias to Generator::send($value)

[S.A.N]

Many interfaces work with callback functions, but they might work with
the generators, if there was a method Generator::__invoke($value).

I apologize if this topic has been discussed.
Thank.

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

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

[S.A.N]

> I don't think we should wait, I was just thinking that it might not be ready
> until that time.
>
> Also, if we plan on rewriting streams and I/O to all be async and use libuv
> underneath, that would probably be a BC break unless the existing functions
> just become blocking interfaces for a separate async API. If it was a large
> BC break, it probably would need to wait for PHP 8.
>
> Now that I think about it, that would be our chance to replace stream
> resources with classes...
>
> $file = \php\stream::open("file.txt");
> $bytes = await $file->read(1024);
> $file->close();
>
> Then rewrite fread() and friends to be aliases that block instead of await
> results.

This is a great opportunity to normalize API standard libraries PHP :)

> $bytes = await $file->read(1024);

It is rarely necessary, more often needs

$result = await $db->query($sql);
and
$result = await $noSql->get($key);

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

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

[S.A.N]

>> /Legend speaks of such plans, but they come and go in whispers. Like a
>> shadow, or a mist from the east. The prophecy spake of such features
>> targeting PHP8; lo, most believe it to be myth./
>
>
> Why do we have to wait until PHP 8? Should be mostly backwards compatible
> and be fine in 7.2 or so. Issue is probably more deciding on an API.
>
>

Yes, I think so, too, do not need to wait for version 8, can start
7.1-2 possible even as another SAPI.

P.S.
These works will accelerate 5x-10x
https://gnugat.github.io/2016/04/13/super-speed-sf-react-php.html

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

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

[S.A.N]

> I think we can spoonfeed the massive undertaking a bit by spreading it
> across several iterations just to get things going. An idea I had was to
> just begin by providing coroutines as part of the language. That would
> include a `\Coroutine` class, as well as await / async keywords. This would
> at least enable third party async libraries to be more compatible since they
> would have the same await types and semantics.
>
> The next step (or at the same time as the first) is to provide some sort of
> `\EventLoopInterface` along with
>
> \EventLoop::getLoop(): \EventLoopInterface
> \EventLoop::setLoop(\EventLoopInterface)
> \EventLoop::run()
> \EventLoop::stop()
> \EventLoop::tick()
>
> To start out, just provide the internal coroutine scheduler as a default
> implementation. Coroutines would use the "event loop" to schedule resumes.
>
> Doing so would allow even more interoperability if a library chose to
> implement `\EventLoopInterface` in its event loop, where it handles
> coroutine scheduling (or lets it fall back to the internal one), and could
> also provide I/O "extras".
>
> The final step would be to bring libuv into PHP, itself as a better default
> implementation of `\EventLoopInterface`.
>
EventLoop interface, on development stage:
https://github.com/async-interop/event-loop

PHP wrappers for libev and libeio supported PHP 7.
https://pecl.php.net/package/ev
https://pecl.php.net/package/eio

libuv - certainly better because it has everything you need and a huge
community.

Very need async/await in the PHP core (based on generators).
Perhaps there are plans in core developers, for implement async/await?

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

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[S.A.N]

2016-04-26 10:44 GMT+03:00 Remi Collet <r...@fedoraproject.org>:
> Le 25/04/2016 à 16:09, S.A.N a écrit :
>> In userland  lacks the ability to store data in the shared memory
>> modules, do not use pecl modules, it would be very nice to have a
>> function:
>>
>> opcache_get($key);
>> opcache_set($key, $value);
>
> Opcache is an opcode cache.
>
> A user data cache is something really different.
>
> We learn from the past, having both in the same extension (APC) was an
> mistake.
>
> So I really think, this doesn't have to be added in opache.
>
> And various extensions already exist (apcu, yac, memcache(d), redis...)

Ok, I agree.
Thank.

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

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[S.A.N]

> Meanwhile, you haven't addressed the point being made as a reason not to
> bundle, which is that this is not a universally-useful solution, and there
> needs to be some reason why this needs to be incorporated - under whatever
> name - any more urgently than a memcache driver, or a redis driver, or
> igbinary serialisation, or any one of dozens of other extensions.

Redis, Memcached - single threaded and network latency.

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

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[S.A.N]

2016-04-25 20:56 GMT+03:00 Rowan Collins <rowan.coll...@gmail.com>:
> S.A.N wrote on 25/04/2016 18:49:
>>>
>>> There's not really a huge connection between opcode caching and
>>> optimization
>>> >(OpCache) and shared memory data caches (APCu, memcached, etc), so I
>>> > don't
>>> >think there's any particular logic to calling such functions "opcache".
>>> >
>>> >So I guess the question becomes: "should APCu be made part of core?" I'm
>>> > not
>>> >aware of anyone having proposed that, so don't know if there are strong
>>> >feelings for or against such a thing.
>>
>> Yes, there are a lot of libraries to work with shared memory, but why
>> should they if there OPcache in core PHP?
>> Functions get, set key values will be useful and in demand.
>
>
> Because different situations call for different functionality. If the only
> reason not to use APCu was the need to install a PECL extension, then nobody
> would have implemented a PECL extension for Memcache, or Redis, etc.
>
> Storing data in PHP's shared memory has several downsides - for instance,
> inability to share with CLI / services built in other languages,
> non-persistent across server restarts, not shareable across instances, etc.
> For you, these may not be an issue, but to say that "if APCu functionality
> was in core, nobody would need any other memory cache" is somewhat naive.

I am not against third-party libraries, I want to have this
functionality out of the box, it seems to me correct to make these
functions in OPCache, instead of adding  Apcu to PHP core, IMHO...

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

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[S.A.N]

2016-04-25 17:36 GMT+03:00 Rowan Collins <rowan.coll...@gmail.com>:
> S.A.N wrote on 25/04/2016 15:09:
>>
>> In userland  lacks the ability to store data in the shared memory
>> modules, do not use pecl modules, it would be very nice to have a
>> function:
>>
>> opcache_get($key);
>> opcache_set($key, $value);
>>
>> Is planned in PHP 7.1?
>>
>
> This was identified as a difference between APC and OpCache when the latter
> was added to core several releases ago, and that's exactly why APCu exists:
> http://php.net/apcu
>
> There's not really a huge connection between opcode caching and optimization
> (OpCache) and shared memory data caches (APCu, memcached, etc), so I don't
> think there's any particular logic to calling such functions "opcache".
>
> So I guess the question becomes: "should APCu be made part of core?" I'm not
> aware of anyone having proposed that, so don't know if there are strong
> feelings for or against such a thing.

Yes, there are a lot of libraries to work with shared memory, but why
should they if there OPcache in core PHP?
Functions get, set key values will be useful and in demand.

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

[PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[S.A.N]

In userland  lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:

opcache_get($key);
opcache_set($key, $value);

Is planned in PHP 7.1?

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

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

[S.A.N]

2016-04-19 19:54 GMT+03:00 David Zuelke :
> I think this solution is merely a band-aid for a more profound architectural 
> weakness of current PHP setups, where a web server call out to the engine 
> (via embedding or FastCGI) to execute a script, which causes this recurring 
> initialization overhead in the first place.
>
> The future is (or should be) servers implemented fully in PHP code (e.g. 
> PHP-PM), just like every other comparable language (Ruby, Python, Java, ...) 
> already does. That also brings many other benefits, such as the ability to 
> handle upgrades to WebSockets in the same codebase, stream request bodies as 
> they're being uploaded, and so forth.
>
> And the performance figures that PHP-PM delivers with Symfony validate that 
> approach IMO.
>

I agree, and developers are already discussing a common event-loop API:
https://github.com/async-interop/event-loop

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

Re: [PHP-DEV] Re: New RFC draft "static class constructor"

[S.A.N]

2015-04-28 11:29 GMT+03:00 Johannes Ott :
> Am 13.04.2015 um 15:37 schrieb Johannes Ott:
>> Hi,
>>
>> finally I managed to do my first RFC draft.
>>
>> https://wiki.php.net/rfc/static_class_constructor
>>
>> I hope I have done everything correct so far and I'm looking forward to
>> your feedback on it.
>>
>> As I already mentioned in the prediscussion thread here:
>>
>> For being my first change to the PHP core, I would be very happy, if
>> someone of the "old stager" would help me with the implementation of
>> this RFC if it is accepted.
>>
>> Regards
>>
>
> Hi there,
>
> there was a really bad situation in my life the last week, so I'm not
> able to do anything on this Draft for some days, I will pause it for
> some weeks now
>
> Regards
>
> --
> DerOetzi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Hi.

Is any progress on the implementation?

Thank.

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

[PHP-DEV] Re: [RFC Proposal] Null Coalesce Equal Operator

[S.A.N]

2016-04-12 18:36 GMT+03:00 Midori Koçak :
> what is sugar?
>

Here is a description:
https://en.wikipedia.org/wiki/Syntactic_sugar

But my proposal, almost not realistic implement, although I may be
mistaken... ;)

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

Re: [PHP-DEV] Re: [RFC Proposal] Null Coalesce Equal Operator

[S.A.N]

Maybe even more sugar? :)

getValueFromDB();

 // Methode getValueFromDB() called, if $value not transmitted or null value
 public function __construct($value ??= $this->getValueFromDB())
 {
  //...
 }

 public function getFromCache()
 {
  // Methode getValueFromDB() called, once upon init static $value
  static $value ??= $this->getValueFromDB();

  return $value;
 }
}

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

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuringassignment

[S.A.N]

Maybe in the future when there will be an inline object {}, you will
need to make the destructuring {}

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

Re: [PHP-DEV] [RFC][VOTE] Allow specifying keys in list()

[S.A.N]

Often all keys are unknown, or a very lot keys, use list(...) - is unreal.

I would like to, instead  $value)
{
 $this{$key} = $value
}

Use the short syntax sugar 

It's really do?

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

Re: [PHP-DEV] [RFC][VOTE] Allow specifying keys in list()

[S.A.N]

2016-02-12 16:27 GMT+02:00 Rowan Collins <rowan.coll...@gmail.com>:
> S.A.N wrote on 12/02/2016 13:37:
>>
>> Often all keys are unknown, or a very lot keys, use list(...) - is unreal.
>>
>> I would like to, instead >
>> foreach($params as $key => $value)
>> {
>>   $this{$key} = $value
>> }
>>
>> Use the short syntax sugar >
>> $this += $params
>>
>> ?>
>>
>> It's really do?
>>
>
> If the keys are unknown, then you probably don't want to blindly copy them
> onto object properties; at that point, you might as well just have
> $this->data and leave them as an array. It sounds like what you actually
> want is an object literal syntax - i.e. $params should never have been an
> array in the first place.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

I would operator (+=) as like to function Object.assign()
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign

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

Re: [PHP-DEV] [RFC][VOTE] Allow specifying keys in list()

[S.A.N]

2016-02-12 16:55 GMT+02:00 Rowan Collins <rowan.coll...@gmail.com>:
> S.A.N wrote on 12/02/2016 14:39:
>>
>> 2016-02-12 16:27 GMT+02:00 Rowan Collins <rowan.coll...@gmail.com>:
>>>
>>> S.A.N wrote on 12/02/2016 13:37:
>>>>
>>>> Often all keys are unknown, or a very lot keys, use list(...) - is
>>>> unreal.
>>>>
>>>> I would like to, instead >>>
>>>> foreach($params as $key => $value)
>>>> {
>>>>$this{$key} = $value
>>>> }
>>>>
>>>> Use the short syntax sugar >>>
>>>> $this += $params
>>>>
>>>> ?>
>>>>
>>>> It's really do?
>>>>
>>> If the keys are unknown, then you probably don't want to blindly copy
>>> them
>>> onto object properties; at that point, you might as well just have
>>> $this->data and leave them as an array. It sounds like what you actually
>>> want is an object literal syntax - i.e. $params should never have been an
>>> array in the first place.
>>>
>> I would operator (+=) as like to function Object.assign()
>>
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign
>
>
> Sure, but I was thinking more in terms of whether this is a strong use case
> for having it. In JS, "Object" is the appropriate type for an arbitrary hash
> of key-value pairs. In PHP,  the appropriate type for such a structure is
> "array", which already supports the + operator and array_merge function.
>
> Note that the method you linked doesn't copy from an array onto an object,
> it copies from one object to another. Doing the same in PHP leaves the
> question of how you create the right-hand object, which is why I mentioned
> "object literal syntax", i.e. the ability to write something like "{ a =>
> 42, b => 'Hello' }" or "new Foo { a => 42, b => 'Hello' }" to define an
> object with directly-specified property values, rather than running the
> constructor.
>
> The constructor example using list() syntax is deliberately naming the
> fields we're interested in, because it's populating an object of a
> particular class, with known property names, not dynamically creating
> arbitrary property keys.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

I agree, list() syntax and object literal syntax - is need, +1
But is also necessary and the function or operator like
object_assign($target, ...$sources)

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

Re: [PHP-DEV] [RFC][VOTE] Allow specifying keys in list()

[S.A.N]

2016-02-12 17:15 GMT+02:00 Rowan Collins <rowan.coll...@gmail.com>:
> S.A.N wrote on 12/02/2016 15:13:
>>
>> But is also necessary and the function or operator like
>> object_assign($target, ...$sources)
>
>
> Like I say, for that kind of purpose, I'd just use an array, which already
> has the facilities for working with arbitrary keys. But I know some people
> think $foo->bar "looks prettier" than $foo['bar'], and make big trees of
> stdClass objects, so maybe it's a matter of taste.

It's not just a matter of taste, the object is always passed by
reference, an array is copied when you change, object literal syntax
like JSON, sorely lacking in PHP.

Probably more correct to focus on the implementation of object literal syntax.
Thank.

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

Re: [PHP-DEV] [RFC] Allow specifying keys in list()

[S.A.N]

> How feasible would it be to add an exception to mixed keys? I'm thinking
> list(7 => $a, $b, $c, $d) to specify an initial offset, similar to how you
> can define an array as [7 => 0, 1, 2, 3]. This obviously goes hand in hand
> with my desire for variable keys :)

I would like it to be like, destructuring assignment, in ES6
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

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

Re: [PHP-DEV] RFC proposal for alternative list syntax

[S.A.N]

It looks like, destructuring assignment, in ES6
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

I like! )

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

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

[S.A.N]

> Implementing elegant, readable, and stable asynchronous code in userland PHP 
> code is very possible. In fact, I’ve done exactly this with Icicle 
> (https://github.com/icicleio/icicle). Icicle uses generators and promises to 
> implement coroutines. When a coroutine yields a promise, the coroutine is 
> interrupted until the promise resolves, sending or throwing the resolution 
> value into the generator. While a coroutine is interrupted, other code in the 
> program is given the chance to be executed. This behavior is similar to 
> async/await, instead using a generator as the async function and yield as 
> await. There are several packages available for Icicle that implement 
> non-blocking I/O and concurrency (multithreading). There are no extensions 
> required for Icicle and no black magic – just making good use of the tools 
> already available.
>

My experience says that callback, promise, yield, not transparent as
the async/await in С#.
In other languages:

Python - coroutines with async and await
https://www.python.org/dev/peps/pep-0492/

ECMAScript
https://github.com/lukehoban/ecmascript-asyncawait

When Node.js appear async/await, many developers and projects will
migrate to a Node.js, if PHP is not implement async APIs.

Hopefully, Dmitry Stogov and others, will make another surprise:
PHP-Next-Async? :)

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

[PHP-DEV] async/await - is future reserved words in PHP 7.x?

[S.A.N]

Are there any future plans for - async/await?
This need to know now, not to use these words to constants, and class names...

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

Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

[S.A.N]

+1 Yes, it is useful to have in the PHP core.
Possible names: $_BODY, $_DATA, $_INPUT, $_REQUEST

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

Re: AW: [PHP-DEV] [RFC] [Discussion] Short Closures

[S.A.N]

I like many the developers of PHP, write JS lot code, very beg you, if
you can do syntax in ECMAScript 6 (=>)

Thank.

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

Re: [PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

[S.A.N]

2015-07-23 18:10 GMT+03:00 Marcio Almada marcio.w...@gmail.com:
 Hi, you replied to the wrong thread ;)

 2015-07-22 19:38 GMT-03:00 S.A.N ua.san.a...@gmail.com:
 I am satisfied, the possibility of group declarations, but the that lack:

 ?php

 use App\RestException\   // name RestException, not imported to
 current namespace :(
 {
 Gone,
 NotFound,
 BadRequest
 };

 ?

 Unfortunately have to write so:

 ?php

 use App\RestException;
 use App\RestException\{Gone, NotFound, BadRequest};

 ?

 It looks ugly and very strange.

 There is nothing strange on it (except, possibly, the trailing `\`
 which was discussed to death and voted).

 Even if we had no trailing '\' it wouldn't make any sense to import
 App\RestException when use App\RestException{Gone, NotFound,
 BadRequest}; is used.

 My proposition, the imported end name, if end of without slash.

 Like this:

 ?php

 use App\RestException
 {
 Gone,
 NotFound,
 BadRequest
 };

 echo RestException::class; // App\RestException

 ?

 Importing from within a namespace is not the same thing as importing a
 class. I'd be against it.

 My 2 cents: why do you have RestException with Exception suffix
 and then don't have the same suffix on the other exception names? This
 unpredictable exception hierarchy is the ugly part and subtle
 alternative syntax won't make it better, IMMO.

 Marcio

RestException is the base class for classes Gone, NotFound, BadRequest...
He needed to catch all RestExceptions class.

We do not use suffixes for names of exception classes, simple clear
named classes of exceptions, this is our agreement.

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

Re: [PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

[S.A.N]

I am satisfied, the possibility of group declarations, but the that lack:

?php

use App\RestException\   // name RestException, not imported to
current namespace :(
{
Gone,
NotFound,
BadRequest
};

?

Unfortunately have to write so:

?php

use App\RestException;
use App\RestException\
{
Gone,
NotFound,
BadRequest
};

?

It looks ugly and very strange.
My proposition, the imported end name, if end of without slash.

Like this:

?php

use App\RestException
{
Gone,
NotFound,
BadRequest
};

echo RestException::class; // App\RestException

?

2015-03-11 11:08 GMT+02:00 Patrick ALLAERT patrickalla...@php.net:
 Le mar. 10 mars 2015 à 19:29, Marcio Almada marcio.w...@gmail.com a
 écrit :

 Hi,

 2015-03-10 11:39 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:

 Hello,

 Le ven. 6 mars 2015 à 00:44, Marcio Almada marcio.w...@gmail.com a
 écrit :

 You are right about this. I'll setup a yes/no vote + a vote to decide
 between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me
 this
 is just a detail but maybe it's very important to others, so better to
 let
 each voter decide upon it.


 In case of language changes, shouldn't the 2/3 of majority be required at
 any levels?


 I don't think it's possible. What would happen if the yes/no vote passes
 but the secondary vote doesn't reach 2/3 for some option? This would be a
 weird situation.


 Pretty simple actually: it would simply not pass because it wouldn't gather
 enough support.

 Discuss the options, see what gather the most support and the better
 reasonings and then suggest that the RFC yes vote means A, B or C while
 summarizing the reasons of the choice for it in the RFC itself.

 A language change vote requiring 2/3 majority on a Yes/No and a simple
 majority in an option basically means not requiring 2/3 at all, but 50%
 (with 2 options) at most!

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

Re: [PHP-DEV] PHP7 and types

[S.A.N]

Maybe implement getter/setter as ECMAScript 6?

class Person
{
get name ():string   { return $this._name }
set name (string $value) { $this._name = $value }
}

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

Re: [PHP-DEV] PHP7 and types

[S.A.N]

Yes, I think the compiler could compile the expression

class Bar
{
   public Foo $foo; // That is shorthand getter/setter...
}

to

class Bar
{
   get foo():Foo {return $this-_foo};
   set foo(Foo $obj) {$this-_foo = $obj};
}

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

Re: [PHP-DEV] PHP7 and types

[S.A.N]

Of course the main target - check types, but not all use the check
types, but almost everyone uses Ide, so I said, it is actual and
useful.

I do not see contradictions, everyone who wants to write PHP 5 code,
need use DocBlock @var.

I hope that in the PHP 7.x, DocBlock is only for documentation of
code, all declared types be in the language and not in the comments

I would like it to be implemented, not beginning of unnecessary disputes.

Thank.

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

Re: [PHP-DEV] PHP7 and types

[S.A.N]

+1
It will be useful for autocomplete in IDE

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

Re: [PHP-DEV] Fix division by zero to throw exception (round 2)

[S.A.N]

 You ideally just check if the divisor is 0 and then do the operation.
 And at that point, we should just throw the DivisionByZeroError.

 Honestly, a warning is just the wrong thing to use. Either you enable it 
 (like double division in C) or disable it completely (runtime exception in C).

 I can get behind both, but not behind a warning.


+1

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

Re: [PHP-DEV] New PHP SAPI for Nginx

[S.A.N]

Tons of things in PHP or in libraries called by PHP are
 blocking

Yes, it's not a problem, thread pools for use blocking processes do
not block the main process Nginx.

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

[PHP-DEV] New PHP SAPI for Nginx

[S.A.N]

New versions Nginx, implement thread pools,
http://nginx.com/blog/thread-pools-boost-performance-9x/

I think this is a good opportunity to write a Nginx module (PHP SAPI)
which is to process requests for PHP scripts in processes Nginx.

Quality advantages, as compared with the FPM, no network overhead,
less memory consumption, may be implemented mode ZTS (Zend Thread
Safety).

What do you think about this?
Thank.

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

Re: [PHP-DEV] New PHP SAPI for Nginx

[S.A.N]

 If there is someone willing to implement this (and maintain it), I
 don't see any reason for why this could not be accepted into PHP. I
 would expect such, if implemented by someone, to first be available in
 7.1.0, although we could do exceptions like we did for FPM which came
 in 5.3.3 or something, although that was before tuning to our RFC
 process and such.


Yes, I am rich in ideas, but unfortunately I am not a developer C.

Perhaps this can be done, Antony Dovgal (tony2001), if he would be interested.

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

[PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6

[S.A.N]

?php

const CONST_ARRAY =
[
'key' = 'value'
];

isset(CONST_ARRAY['key']); // Fatal error: Cannot use isset() on the
result of an expression (you can use null !== expression instead)

?

It is design, or a bug?

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

Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6

[S.A.N]

 It is by design; the documentation states[1]:

 | isset() only works with variables as passing anything else will
 | result in a parse error.

 [1]
 http://php.net/manual/en/function.isset.php#refsect1-function.isset-notes

Ok, the way it works in PHP 7.

But the speed of access to const the array (ARR['key']) is 5 times
slower, in comparison with the variable ($arr['key']) :(

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

Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6

[S.A.N]

 There was some discussion on contant arrays on Stackoverflow with an
 answer by Andrea Faulds (with a link to changes between 5.6 and 7.0):
 http://stackoverflow.com/a/27413238/872051

Ok, thank.

Why the speed of access to const the array ARR['key'] is 500% slower,
in comparison with the variable $arr['key']?

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

Re: [PHP-DEV] Static method call with single colon results in fatal error, not a parse error?

[S.A.N]

Foo::bar();

Output for 5.0.0 - 5.6.8, php7@20140507 - 20150501, hhvm-3.6.0 - 3.7.0bar
http://3v4l.org/F6tXZ

2015-05-12 21:44 GMT+03:00 Bishop Bettini bis...@php.net:
 class Foo {
 public static function bar() { echo 'bar'; }
 }
 Foo:bar();


 Note the single colon.  According to 3v4l http://3v4l.org/Ot3Fk...

 5.2.17 and earlier:
 Parse error: syntax error, unexpected ':'

 5.3 and later, including 7 and HHVM:
 Fatal error: Call to undefined function bar()


 Is this really a run-time fatal error?  Unless I missed a memo, surely this
 should be a compile time error.

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

Re: [PHP-DEV] Add support $object::class

[S.A.N]

 $object is not guaranteed to be an object, it could be anything (int,
 string, etc) or nothing (null).  using ::class for a variable, I'd argue,
 makes for less consistency.  What would the replacement be for non-object
 variables?  An error, exception, or false, or string type? At least in
 Bar::class, you'll always get a string representation of what the fully
 qualified class name resolves to.

$scalar::class === gettype($scalar)
$object::class ===  get_class($object)

 That said, the argument could be made that since static::class, self::class,
 and parent::class fall into the same category of potential runtime
 resolutions that $object::class too should be supported.

+1

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

[PHP-DEV] Add support $object::class

[S.A.N]

Now this code causes an error PHP 5-7.

PHP Parse:
Syntax error, unexpected 'class' (T_CLASS), expecting identifier
(T_STRING) or variable (T_VARIABLE) or '{' or '$'

Do not want to use get_class($object)

Thank.

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

Re: [PHP-DEV] Add support $object::class

[S.A.N]

 Why not?

 Seriously, why not? ::class was added because there was no easy way to
 get from the symbol class name to the string representation of it (you
 couldn't pass it to a function, etc since it would look like a
 constant). So ::class is a purely compile time construct to turn a
 literal classname into a string representation.

 However, if you have a variable, there already is a way to do that at
 runtime: get_class. What's the problem with that where we need to
 further support arbitrary syntax?

 Note: I'm not saying we shouldn't add support. I'm just saying that
 it's not the same situation as with Bar::class...


1. get_class($object) - looks bad and long
2. Illogically - Bar::class valid syntax, $object::class invalid syntax.
3. Function call get_class($object) is slower

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

Re: [PHP-DEV] Add support $object::class

[S.A.N]

2015-04-27 20:33 GMT+03:00 Nicolas Grekas nicolas.gre...@gmail.com:

 Systems that depend on `get_class()` a lot would

 An for non-objects types, I suggest that $var::class could return the same
 as get_type($var). That would allow saving ref mismatches when $var is a
 ref.

+1

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

Re: [PHP-DEV] New RFC draft static class constructor

[S.A.N]

 Okay I will think about the alternative names, I somehow like
 __classInit you proposed or __classConstruct

I like simple: __init()

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

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

[S.A.N]

 Then how would you write an callback containing an already constructed object?
 $a = [$object, 'method'];

 The alternative is unnecessarily cumbersome:
 $a = function($methodArg1, $methodArg2) use($object) { return
 $object-method($methodArg1, $methodArg2); };

$object-$methodName(...$args);

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

Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC

[S.A.N]

 Someone got an idea ?

Simply arrows, without word this

?php
class Addition {
  private $number

  public function __construct($number) {
$-number = $number;
  }

  public function original() {
return $-number;
  }

  public function addTo($amount) {
return $-number + $amount;
  }
}

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

Re: [PHP-DEV] Consistent function names

[S.A.N]

2015-03-02 2:17 GMT+02:00 Terry Cullen te...@terah.com.au:
 On 2 March 2015 at 01:18, S.A.N ua.san.a...@gmail.com wrote:

 Maybe better implement for method calls on primitive types in PHP 7?
 https://github.com/nikic/scalar_objects


 I've searched through the internals archive looking for debate on using
 scalar objects without much luck.  I'd love to see some discussion around
 this as it seems like it would go a long way to resolving some common pain
 points in PHP without BC like:

- type hints
- inconsistant function naming
- needle/haystack
- unicode

 And, the method chaining of common string/array manipulations makes for
 cleaner, easier to read code.


+1

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

Re: [PHP-DEV] Consistent function names

[S.A.N]

Maybe better implement for method calls on primitive types in PHP 7?
https://github.com/nikic/scalar_objects

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

Re: [PHP-DEV] [RFC] Anonymous Classes

[S.A.N]

Would have been more useful, inline sintex like JSON:

$object =
{
'property': $value,
'method':  function (){...}
};

$object-property;
$object-method();

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

Re: [PHP-DEV] [RFC] Anonymous Classes

[S.A.N]

2015-02-24 20:49 GMT+02:00 Philip Sturgeon pjsturg...@gmail.com:
 On Tue, Feb 24, 2015 at 1:37 PM, S.A.N ua.san.a...@gmail.com wrote:
 Would have been more useful, inline sintex like JSON:

 $object =
 {
 'property': $value,
 'method':  function (){...}
 };

 $object-property;
 $object-method();

 I know what you're saying here, and object literals like this would be
 rather interesting someday. They are, however, quite different to the
 concept of anonymous classes.

 JSON syntax would make it very hard for the usual PHP functionality to
 be used. Properties and methods look the same, visibility scopes
 cannot be used, implementing interfaces becomes impossible, traits
 dont have a home, etc. By the time you have catered to all of that you
 have something very different to JSON, and very different to PHP.

 Or, you have the syntax being proposed here, which is identical to
 existing declared class syntax other than there being no name.

 Another RFC to replace $foo = (object) [ 'foo' = 'bar' ]; someday
 would be nice, but that is not what this is up to.

Yes, is problem - properties and methods look the same, how to solve
this problem in PHP I do not know.
Perhaps PHP could interpret this code:
$object =
{
'property' = $value,
'method' = function (){...}
};

AS

$object = new class
{
  public $property = $value;
  public function method (){...}
}

Use case - inline object without inheritance and traits, only the
properties and methods it brief and easily understood JSON syntax, I
think it would be popular with developers of PHP.

Thank.

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

Re: [PHP-DEV] A modest proposal: __contructStatic

[S.A.N]

2015-02-15 21:04 GMT+02:00 Patrick Schaaf p...@bof.de:
 Hello Internals,

 seeing the static calling of instance methods being discussed again, I want
 to ask whether the following idea would maybe have a chance?

 In our codebase we have one set of classes where it was very useful to be
 able to call the same methods both statically and nonstatically: a set of
 wrapper classes over phpredis where subclasses know which set of redis
 servers to talk to (plus other config like retry strategies and timeouts).
 In most cases calling code does not need to be concerned with these details
 and just calls methods like red_global::get() or red_local::put().

 By neccessity the implementation of this class set, must make use of both
 __call() and __callStatic() magic methods, with both then dispatching to a
 delegate phpredis instance, and in the case of __callStatic(), making
 up-front a singleton like new self once. For a set of additional helper
 methods (not present on the underlying phpredis) I additionally have a
 special mapping array of real method names to internal implementation names.

 A similar approach can be useful for database connection abstraction
 classes.

 Now for the idea how this might be made much more simple: onviously in the
 light of the static call to method using $this warning/detection, PHP
 already knows exactly where it hits such a static call to an instance
 method. At that point, check whether the class has a static instance
 already. When it has one, call the method with $this being that static
 instance. Otherwise, create the static instance, calling a new magick
 method named __constructStatic() to initialize it. Only classes that have
 such a __constructStatic() method, would be treated that way. For other
 classes the static call to instance method case would be an error as
 before/discussed.

 This approach would clearly simplify my redis wrapper classes, maybe even
 enable them to be proper subclasses of phpredis (saving an indirection to a
 $this-delegate object). All the special dispatch and __callStatic
 instantiation logic could go away.

 The cost would be one internal pointer (to the static instance object)
 per class, a kind of hidden static protected property, and only needed
 when the class (or one of its superclasses) _has_ a __constructStatic
 method in the first place.

 What do you all think? Interesting? Somebody hot for helping with
 impementation? Then I'd make an RFC of it.

 best regards
   Patrick

+1

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

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

[S.A.N]

2015-02-14 2:38 GMT+02:00 Leigh lei...@gmail.com:
 On 14 February 2015 at 00:32, Benoit Schildknecht bensor...@neuf.fr wrote:
 I don't think EngineException should inherit from Exception, it would be
 very dangerous. I'm sure a lot of exceptions are handled like this by a lot
 of devs, without creating custom exceptions :


 Agreed, EngineException should be a base type of it's own.

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


May be better: PHP\Exception?

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

Re: [PHP-DEV] Design by Contract

[S.A.N]

2015-02-11 13:25 GMT+02:00 Dmitry Stogov dmi...@zend.com:

 yes. some special attributes. requires/ensures/invariant


 Oh, and  syntax is *ugly* ;)


 It's from HHVM. I don't like it as well, please, propose the better one.


I like syntax, like a switch:

function add(int $a, int $b) : int
case $a  0:
case $b  0:
return($ret, $ret  0, something wrong)
{
return $a + $b;
}

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

Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[S.A.N]

2015-02-10 14:26 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
 Rowan Collins wrote on 09/02/2015 18:24:
 I just realised the double negative in that sentence may not be easy to
 understand, so just to make sure it's clear: I do quite like the idea, in
 general, but think it would require a major rethink of large parts of code.
 We need only look at PHP 6/Unicode for the risks involved in a
 well-intentioned feature with far-reaching impact on the language.

 I also think that an application server model without userland threads would
 be a mistake, because it would still be difficult to share anything
 meaningful between requests.

 That said, if someone wants to start collecting a top-level list of what
 would need to be changed, and suggesting how it might work, I'd be happy to
 contribute some ideas.


Yes, I understand you correctly, thank you.

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

Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[S.A.N]

2015-02-09 12:41 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
 Yes, I can see it working well for specialised uses - you can simply not use 
 those aspects of the language that don't make sense. But for it to be a 
 mainstream part of the language, it needs to play nicely with other parts of 
 the language, and that's where I see it being a complex and painful change.


The fact that the lack of native application server for PHP is often
the reason for leaving the PHP developers to other languages and
technologies.

Let's see what others have in 2015:

Python - WSGI
Ruby - Rack
Perl - PSGI
JavaScript - JSGI
Hack - HHVM

PHP - No native application server in core.

What discusses the PHP community?
Remove or not to remove the PHP4 constructors and many other issues
that do not add competitive ability PHP...

I personally do not blame you :), just expressing his opinion
developer who wants to use PHP and can use modern app server in core
PHP.

Thank.

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

[PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[S.A.N]

Hi internals.

I really hope that in the future PHP 7, there will be new server API.
May be you interested to know about them, here is the link, I am not
the author of development:
https://github.com/unbit/uwsgi-phpsgi/

But the problem is that in PHP there are no standards for such interfaces.
Now it is implemented like this:

?php

function application($env)
{
 return ['200 OK', ['Content-Type' = 'text/plain'], 'Hello, world!'];
}

?

I think this is a good opportunity to review the old interface ($_GET,
$_POST, ...) and start using the API internal HTTP module.

This all breaks backward compatibility, not $_GET, $_POST, ...
But this WSGI SAPI will used only new PHP code (not PHP legacy base).

This is a good opportunity to create something new and not be backward
compatible.

What do you think about this?

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

Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[S.A.N]

2015-02-09 2:26 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
 On 09/02/2015 00:02, S.A.N wrote:

 You're right, but there is no threading issues.
 One worker synchronously execute requests, but may run parallel many
 workers.


 I'm not sure what you mean by this. I can see 3 ways of handling incoming
 web requests, as it affects PHP's threading:

 A) The current shared nothing model: the web server may have multiple
 processes or threads, but each requested is executed in a completely
 separate global scope of PHP.
 B) Each process or thread in the web server spawns an instance of the
 application; the application has a global state within that instance, and
 startup and shutdown code; the instance is sent multiple requests, but has
 no way to know if it is getting all the requests, half the requests, or one
 hundredth of the requests.
 C) The web server executes the application once, which sets up its global
 state, and then spawns an internal threading model; each request is sent to
 a worker thread within PHP, which has to synchronise with other threads in
 order to access any aspect of global state.

 I guess you are suggesting option (B), which is what I was referring to when
 I said that global state would be arbitrarily shared - if handling a
 particular request caused any global state to be changed, such as
 registering an error handler, it could affect anything from 0 to 100% of
 subsequent requests, depending on how the web server is configured.

 The code therefore needs to avoid relying on any such global state at all,
 which basically restricts you to a subset of the current language. For it to
 become the default way of running PHP, huge changes would be needed to adapt
 code to this new model.

 The reason I mentioned threading is that under option (C), migration becomes
 a bit easier in some ways: you can move some things which are currently
 global state into an explicitly per-thread state, allowing old behaviour to
 be emulated; and you can leave other things in synchronized global state,
 like ini settings, solving the problem of 50% of my threads have a
 different error handler registered.


 Regards,

 --
 Rowan Collins
 [IMSoP]


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


Yes, option (B) is more like.

Let me show in your PHP code, how the option that I like, we have the
actual application work that way in the pecl-event module, we are
satisfied, it is convenient and very fast for PHP.

This is a very rough and simplified code:
?php

class App
{
public static $db;// Persistent open connection to database
public static $redis; // Persistent open connection to Redis
public static $cache; // Persistent cache application

public $request;
public $response;
public $session;

public function __construct(HTTP $object)
{
$this-request  = $object-request;
$this-response = $object-response;
}

public function open()
{
/*
   Routing by $this-request, may be auth and open
$this-session (analog $_SESSION), or throw Exception.
*/

return $this;
}

public function run()
{
/*
   Run your business logic...
*/

return $this;
}

public function close()
{
/*
   Run finally logic, and cleaning output buffer
*/

$this-response-body = ob_get_clean();

return $this;
}

public static function init()
{
/*
   Application configuration as static class state
*/

ob_start();
set_error_handler(/*...*/);

self::$db= new DBConnection;
self::$redis = new Redis;
self::$cache = new Cache;
}
}

// Bootstrap, run configuration
App::init();

// Handler WSGI (not multi-thread)
function application(HTTP $object)
{
$app = new App($object);

$app-open()-run()-close();

return
[
$app-response-code,
$app-response-headers,
$app-response-body
];
}

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

Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[S.A.N]

2015-02-09 1:48 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
 On 08/02/2015 22:48, S.A.N wrote:

 Hi internals.

 I really hope that in the future PHP 7, there will be new server API.
 May be you interested to know about them, here is the link, I am not
 the author of development:
 https://github.com/unbit/uwsgi-phpsgi/

 But the problem is that in PHP there are no standards for such interfaces.
 Now it is implemented like this:

 ?php

 function application($env)
 {
   return ['200 OK', ['Content-Type' = 'text/plain'], 'Hello, world!'];
 }

 ?

 I think this is a good opportunity to review the old interface ($_GET,
 $_POST, ...) and start using the API internal HTTP module.

 This all breaks backward compatibility, not $_GET, $_POST, ...
 But this WSGI SAPI will used only new PHP code (not PHP legacy base).

 This is a good opportunity to create something new and not be backward
 compatible.

 What do you think about this?


 The problem with creating an event-based API for PHP is that you don't just
 have to rethink superglobals, you have to rethink absolutely everything that
 currently acts as global state:

 - global variables
 - static variables within functions
 - class static variables
 - dynamic settings (ini_set etc)
 - globally registered callbacks (set_error_handler, spl_autoload_register,
 etc)
 - the counters of include_once() and require_once()
 - any function which implicitly fetches data based on some previous action
 (e.g. libxml_get_errors)

 If the language is not itself multi-threaded, all of these become
 arbitrarily shared once per thread the server spins up and reuses. If it
 *is* multi-threaded, you have another set of headaches about how both the
 engine and the userland can share and synchronize.

 Not that I don't like the idea, but it's a huge project, with potential for
 profoundly affecting the language.

 Regards,

 --
 Rowan Collins
 [IMSoP]


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


You're right, but there is no threading issues.
One worker synchronously execute requests, but may run parallel many workers.

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

Re: [PHP-DEV] What do we need strict scalar type hints for?

[S.A.N]

We all external data convert to native PHP types.
The database we use option MYSQLI_OPT_INT_AND_FLOAT_NATIVE.
HTTP inputs are validated and converted to native PHP types.
In Redis data are stored as serialize string.

Strong typing I like.

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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[S.A.N]

2015-02-02 21:12 GMT+02:00 Andrea Faulds a...@ajf.me:
 Hi Dmitry,

 On 2 Feb 2015, at 18:22, Dmitry Stogov dmi...@zend.com wrote:

 So, one of the advantages of strict type hinting is the ability to catch 
 potential errors.
 For example when we pass 67 to setBody(string $message).

 Yes, that sort of thing is easily caught by strict type checks. They’re also 
 able to catch things that are sometimes okay for weak hints, sometimes not. 
 For example, some *but not all* strings are accepted for integer and float 
 parameters, and some *but not all* floats are accepted for integer 
 parameters. Strict checks make this much simpler and not dependant on the 
 value: either some type is accepted, or it isn’t.

 Because of that, strict types can actually be effectively analysed 
 ahead-of-time by static analysers, IDEs and so on, and so you can catch some 
 types of errors while editing your code, without even needing to run it. This 
 is quite a powerful feature. Nikita might have more to say on that.

 Thanks.
 --
 Andrea Faulds
 http://ajf.me/





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


Strict type checking, has its advantages.

We all external data convert to native PHP types.
The database we use option MYSQLI_OPT_INT_AND_FLOAT_NATIVE.
Inputs are validated and converted to native PHP types.
In Redis data are stored as serialize string.

In our API we may require strict adherence to type because the integer
as strings $id = 123 to impossible, i need catch these as logical
error.

But I also fully endorse, cast without loss of accuracy, because it
gives you more options and less of a problem for those who do not have
the conversion of external data.

Not to discuss endlessly two options, it is reasonable send to voting
the Strict type checking, voting will be fail :), then will be easier
to discuss technical issues as do korektno cast without losing data,
good luck!

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

Re: [PHP-DEV] Use caller keyword, to access object caller.

[S.A.N]

2015-02-01 21:41 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
 On 31/01/2015 23:42, S.A.N wrote:

 Yes, you're right, in PHP you can solve this problem by other methods, i
 know...

 But the problem is that PHP is no nice and convenient for solving this
 problem.
 So i suggested to add new keyword, not to do manually bindTo($this)
 for each methods.


 Have a closer look at my example; the point is that without bindTo, there is
 no way of doing the *first* part of your JS example, i.e. attaching the same
 function/method to two objects - there is no equivalent of this line:

 oA.getHolder = getHolder


 In your PHP example, you introduce an extra object, $c, which doesn't exist
 in your JS example; if it did, it would look like this:

 var oA = new A
 var oB = new B
 var oC = new C

 oA.myC = oC;
 oB.myC = oC;
 oC.getHolder = getHolder

 oA.myC.getHolder() // returns C
 oB.myC.getHolder() // returns C


 Hopefully you can see that that makes all the difference - myHolder is now
 always called from the same object, the one created with new C.

 The reason this doesn't translate well is that In JS, a method is just a
 property which happens to be a closure, so this is necessarily dynamic -
 there is no class definition to define the relationship between the method
 and the object (ES6 introduces all sorts of variations and caveats to this,
 all of which can be emulated in older versions). In PHP, a method is
 fundamentally different from functions, closures, and properties, despite
 similarities in syntax, so none of the same behaviours would make sense.


 Regards,

 --
 Rowan Collins

Yes you are right.
In PHP, i added to $holder a sub-object, for two reasons:

1. In PHP, it is impossible
$holder-call = function(){};
$holder-call(); // Error

2. I need to have a common state in $this.
   That's why i decided to add a subobject: $holder-object-call();

But i understand that this is a bad idea.
i originally thought that it simplifies the implementation of
solutions in PHP, but it is not.

Maybe correct option, native implement in PHP - pattern prototype,
then do not need to create new keywords and questionable behavior.

Let me show you an example JS, i want to do in PHP:
script language=JavaScript

var A = {}
var B = {}
var C =
{
object:
{
index: 0
},
method: function ()
{
console.log(this.object.index++)
}
}

A.__proto__ = C
B.__proto__ = C

A.method() // return 0
B.method() // return 1
C.method() // return 2

/script

In PHP, I would like to have an analog method Object.create
http://www.ecma-international.org/ecma-262/5.1/#sec-15.2.3.5
Perhaps the option to add in PHP, new magic static method:
ClassName::__create($object).
This method will create a new instance of the class and introduce API
from specified object.

It would also be very nice to have a method of changing the prototype
at run time, this could be used method: $a-__proto($other)
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-additional-properties-of-the-object.prototype-object

Then the PHP code looks like this:
?php

class A{}
class B{}
class C
{
public $object;

public function __construct()
{
$this-object = new stdClass;
$this-object-index = 0;
}

public function method()
{
return $this-object-index++;
}
}

$c = new C;
$a = A::__create($c);
$b = B::__create($c);

$a-method() // return 0
$b-method() // return 1
$c-method() // return 2

?

If it is technically possible and PHP developers is interesting, then
it is better to create a new topic, to discuss implementation of the
prototype in PHP.

I do not want to break the paradigm of PHP and not impose everywhere
and always use prototypes, I hope that PHP will have a multi-paradigm.

ECMAScript not had classes, but version 6+ implemented class, is nice.
If PHP 7 will be implemented prototypes will be very cool to everyone.

Thank you all.

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

Re: [PHP-DEV] Use caller keyword, to access object caller.

[S.A.N]

No, I'm not describing this behavior, but I chose the wrong name
keyword, this is not perceived correctly.

My source code examples, it is clear that no returns previous object
from the call stack, me need return references to the holder object.

It's more like the dynamic of this in JavaScript.
Dynamic this, sometimes very convenient for the event model, so I
proposed to implement this feature in PHP.
In PHP, there traits, extends, but it's all static bind, in runtime
can not be added or redefined.

I'll show a simple JS example, in which needed behavior dynamic this.
script language=JavaScript

function A(){}
function B(){}

function getHolder()
{
console.log(this.constructor.name)
}

var oA = new A
var oB = new B

oA.getHolder = getHolder
oB.getHolder = getHolder

oA.getHolder() // return A
oB.getHolder() // return B

getHolder() // return Window

/script

Perhaps we should use the keyword this instead of caller? :)
Then the code in PHP will look like this:

?php

class A
{
public $object;
}

class B
{
public $object;
}

class C
{
public function getHolder() {
return this::class;
}
}

$a = new A;
$b = new B;
$c = new C;

$a-object = $c;
$b-object = $c;

$a-object-getHolder(); // return A
$b-object-getHolder(); // return B

$c-getHolder(); // Fatal Error - undefined context

?

What do you think?
Thank.

2015-01-30 18:43 GMT+02:00 Ferenc Kovacs tyr...@gmail.com:


 On Fri, Jan 30, 2015 at 3:53 AM, S.A.N ua.san.a...@gmail.com wrote:

 The reason for creating circular references, usually due to the need to
 bind objects.

 But this relationship can often be obtained from the context of the call.

 It will be very convenient to have a keyword that will return reference to
 an object, which caused this object.

 Sorry for my English, I'm not a native speaker.
 A simple example below shows the behavior that we need.

 ?php

 class A
 {
 public function __construct() {
 $this-object = new C;
 }
 }

 class B
 {
 public function __construct() {
 $this-object = new C;
 }
 }

 class C
 {
 public function getCaller() {
 return caller::class;
 }
 }

 $a = new A;
 $b = new B;
 $c = new C;

 $a-object-getCaller(); // return A
 $b-object-getCaller(); // return B

 $c-getCaller(); // Fatal Error - undefined caller context

 ?

 Create a new keyword can cause problems with backward compatibility...
 Perhaps you can solve a problem to using an existing keyword?

 Thank you for any feedback.


 see the previous discussion on this topic:
 http://grokbase.com/t/php/php-internals/099g86x7k6/reference-caller-object
 I think having it as a magic constant would be better, but I still don't
 like the idea (it is already possible, there aren't really a good usecase
 for it, the example you mentioned is a prime example how would it be misused
 to cause debugging nightmares, etc.).

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

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

Re: [PHP-DEV] Use caller keyword, to access object caller.

[S.A.N]

2015-02-01 2:23 GMT+02:00 Stanislav Malyshev smalys...@gmail.com:
 Hi!

 If  the caller explicitly send the object as an argument, it worsens
 loose depending API.

 And agreed this code looks weird and not well thought-out:
 ?php

 $holder-object-call($holder);

 This code explicitly says object-call() is using $holder. It is clear
 and unambiguous. If you did it implicitly - i.e. wrote
 $holder-object-call() and that used $holder under the hood in call() -
 then you could have modified or even completely destroyed $holder under
 the assumption that nobody depends on it, but in fact whatever is in
 $holder-object, unknown to you, would depend on it and would break.
 Such hidden dependencies are not a good design.

 But if have an easy way to get a pointer to the owner, in practice, is
 very convenient.

 It may be convenient in short run, but I think in the long run creating
 hidden dependencies would make code less robust so it is better not to
 enable it as a best practice.
 --
 Stas Malyshev
 smalys...@gmail.com

Everything is relative, when there is an experience in a dynamic
context (this) in JS, while unwieldy structure in PHP code look
something old and not comfortable.

I think, that purchased experience will be the use of safety culture
dynamic runtime context, many developers it would be appreciated, to
implement this PHP frameworks.

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

Re: [PHP-DEV] Use caller keyword, to access object caller.

[S.A.N]

2015-02-01 0:10 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
 On 31/01/2015 19:41, S.A.N wrote:

 No, I'm not describing this behavior, but I chose the wrong name
 keyword, this is not perceived correctly.

 My source code examples, it is clear that no returns previous object
 from the call stack, me need return references to the holder object.

 It's more like the dynamic of this in JavaScript.
 Dynamic this, sometimes very convenient for the event model, so I
 proposed to implement this feature in PHP.
 In PHP, there traits, extends, but it's all static bind, in runtime
 can not be added or redefined.

 I'll show a simple JS example, in which needed behavior dynamic this.
 script language=JavaScript

 function A(){}
 function B(){}

 function getHolder()
 {
  console.log(this.constructor.name)
 }

 var oA = new A
 var oB = new B

 oA.getHolder = getHolder
 oB.getHolder = getHolder

 oA.getHolder() // return A
 oB.getHolder() // return B

 getHolder() // return Window

 /script

 Perhaps we should use the keyword this instead of caller? :)
 Then the code in PHP will look like this:

 ?php

 class A
 {
  public $object;
 }

 class B
 {
  public $object;
 }

 class C
 {
  public function getHolder() {
  return this::class;
  }
 }

 $a = new A;
 $b = new B;
 $c = new C;

 $a-object = $c;
 $b-object = $c;

 $a-object-getHolder(); // return A
 $b-object-getHolder(); // return B

 $c-getHolder(); // Fatal Error - undefined context

 ?

 What do you think?
 Thank.


 Hi,

 I think I get what you're trying to do, but I'm not sure the PHP code you
 suggest is quite equivalent to the JavaScript. In JavaScript, you are
 setting a single function (getHolder) as a direct member of your objects:

 oA.getHolder = getHolder
 oB.getHolder = getHolder

 But in the PHP, you are attaching a whole object to a property:

 $a-object = $c;
 $b-object = $c;

 When you call getHolder in PHP, the holder of that method is always $c,
 because you could split the code up like this:

 $something = $a-object;
 $something-getHolder();

 In general, a method can't be copied from one object to another in PHP like
 it can in JS, so the concept of dynamic this doesn't normally make any
 sense. However, you can do something similar by binding a closure; you
 just need to invoke it a bit differently because properties and methods are
 not interchangeable like they are in JS:

 ?php

 class A {
 public $getHolder;
 }
 class B {
 public $getHolder;
 }

 $getHolderDefinition = function() { return get_class($this); };

 $a = new A;
 $b = new B;

 $a-getHolder = $getHolderDefinition-bindTo($a);
 $b-getHolder = $getHolderDefinition-bindTo($b);

 echo $a-getHolder-__invoke(), \n;
 echo $b-getHolder-__invoke(), \n;

 // Or

 $method = $a-getHolder;
 echo $method(), \n;

 $method = $b-getHolder;
 echo $method(), \n;



 For many callback / event scenarios, you don't actually need to treat the
 closure as a property / method of the object at all, you just want the $this
 reference, so the -bindTo() part is all you need, maybe more like this:

 class SomeEventTarget {
 function triggerEvent($someCallback) {
 $boundCallback = $someCallback-bindTo($this);
 $boundCallback($some, $arguments);
 }
 }

 (PS: The house rules for this list asks for replies to be below quoted text,
 not above.)

 Regards,

 --
 Rowan Collins
 [IMSoP]



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


Yes, you're right, in PHP you can solve this problem by other methods, I know...

But the problem is that PHP is no nice and convenient for solving this problem.
So I suggested to add new keyword, not to do manually bindTo($this)
for each methods.

Thank.

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

Re: [PHP-DEV] Use caller keyword, to access object caller.

[S.A.N]

2015-02-01 1:52 GMT+02:00 Stanislav Malyshev smalys...@gmail.com:
 Hi!

 The reason for creating circular references, usually due to the need to
 bind objects.

 But this relationship can often be obtained from the context of the call.

 If the API behaves differently depending on who is calling it, or
 requires some information from the caller, it should be passed
 explicitly - as a parameter/method call/etc. - not hidden. Otherwise it
 would lead to nasty surprises when the user of the API assumes caller
 does not matter but the implementor assumes it does.
 --
 Stas Malyshev
 smalys...@gmail.com

This is a controversial statement.
If  the caller explicitly send the object as an argument, it worsens
loose depending API.

And agreed this code looks weird and not well thought-out:
?php

$holder-object-call($holder);

?

Opportunity to shoot yourself in the foot, will always, developers
node.js it know.

I know that this code can be arranged differently, but then you have
to make it more difficult and not nice.

But if have an easy way to get a pointer to the owner, in practice, is
very convenient.

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

Re: [PHP-DEV] Use caller keyword, to access object caller.

[S.A.N]

I will clarify the benefits of the keyword.
Single instance of the class can reused in different contexts calls.

?php

class A
{
public $object;
}

class B
{
public $object;
}

class C
{
public function getCaller() {
return caller::class;
}
}

$a = new A;
$b = new B;
$c = new C;

$a-object = $c;
$b-object = $c;

$a-object-getCaller(); // return A
$b-object-getCaller(); // return B

$c-getCaller(); // Fatal Error - undefined caller context

?

2015-01-30 5:50 GMT+02:00 Juan Basso jrba...@gmail.com:

 Usually it is solved sending the $this instance to class C constructor and
 C object storing it in some attribute, solving the problem. I don't think a
 new keyword would help.

 Juan Basso

 On Thu, Jan 29, 2015 at 9:53 PM, S.A.N ua.san.a...@gmail.com wrote:

 The reason for creating circular references, usually due to the need to
 bind objects.

 But this relationship can often be obtained from the context of the call.

 It will be very convenient to have a keyword that will return reference to
 an object, which caused this object.

 Sorry for my English, I'm not a native speaker.
 A simple example below shows the behavior that we need.

 ?php

 class A
 {
 public function __construct() {
 $this-object = new C;
 }
 }

 class B
 {
 public function __construct() {
 $this-object = new C;
 }
 }

 class C
 {
 public function getCaller() {
 return caller::class;
 }
 }

 $a = new A;
 $b = new B;
 $c = new C;

 $a-object-getCaller(); // return A
 $b-object-getCaller(); // return B

 $c-getCaller(); // Fatal Error - undefined caller context

 ?

 Create a new keyword can cause problems with backward compatibility...
 Perhaps you can solve a problem to using an existing keyword?

 Thank you for any feedback.

[PHP-DEV] Use caller keyword, to access object caller.

[S.A.N]

The reason for creating circular references, usually due to the need to
bind objects.

But this relationship can often be obtained from the context of the call.

It will be very convenient to have a keyword that will return reference to
an object, which caused this object.

Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.

?php

class A
{
public function __construct() {
$this-object = new C;
}
}

class B
{
public function __construct() {
$this-object = new C;
}
}

class C
{
public function getCaller() {
return caller::class;
}
}

$a = new A;
$b = new B;
$c = new C;

$a-object-getCaller(); // return A
$b-object-getCaller(); // return B

$c-getCaller(); // Fatal Error - undefined caller context

?

Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?

Thank you for any feedback.

Re: [PHP-DEV] Use caller keyword, to access object caller.

[S.A.N]

Yes.
But this creates a static link that will not be constantly changing context
to the calls, the keyword will give a dynamic abstract communication.

2015-01-30 5:50 GMT+02:00 Juan Basso jrba...@gmail.com:

 Usually it is solved sending the $this instance to class C constructor and
 C object storing it in some attribute, solving the problem. I don't think a
 new keyword would help.

 Juan Basso

 On Thu, Jan 29, 2015 at 9:53 PM, S.A.N ua.san.a...@gmail.com wrote:

 The reason for creating circular references, usually due to the need to
 bind objects.

 But this relationship can often be obtained from the context of the call.

 It will be very convenient to have a keyword that will return reference to
 an object, which caused this object.

 Sorry for my English, I'm not a native speaker.
 A simple example below shows the behavior that we need.

 ?php

 class A
 {
 public function __construct() {
 $this-object = new C;
 }
 }

 class B
 {
 public function __construct() {
 $this-object = new C;
 }
 }

 class C
 {
 public function getCaller() {
 return caller::class;
 }
 }

 $a = new A;
 $b = new B;
 $c = new C;

 $a-object-getCaller(); // return A
 $b-object-getCaller(); // return B

 $c-getCaller(); // Fatal Error - undefined caller context

 ?

 Create a new keyword can cause problems with backward compatibility...
 Perhaps you can solve a problem to using an existing keyword?

 Thank you for any feedback.

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[S.A.N]

Many developers PHP offers dual syntax:

1. Strict
function bar(int $num){}

2. Lax
function bar((int) $num){}

Maybe it makes sense to put this option on the ballot if it passes a vote,
it will be possible to put an end to the discus?

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[S.A.N]

The main advantage of the two syntaxes:

1. Strict
function bar(int $num){}

2. Weak
function bar((int) $num){}

Any junior-middle PHP developer, seeing this syntax in the code can
understand how it works, without studying the documentation and without
your complex conversion tables.

Explicit is better than implicit, is the motto Python, here it is very
relevant.

Re: [PHP-DEV] [RFC] Scalar Type Hints

[S.A.N]

Syntax forced cast, it makes sense not only for scalar types, but also for
instances of classes.

Is a syntactic sugar can be realized

?php

class User
{
public function __construct(int $id)
{
  ..
}
}

function printPerson((User) $object)
{
   var_dump($object);

   return ($object instanceof User);
}

printPerson(new User(101)); // TRUE

printPerson(101); // TRUE
// scalar int = 101, sent to constructor method class User, the resulting
instance User passed to the function printPerson

Re: [PHP-DEV] [RFC] Additional splat operator usage

[S.A.N]

I always wanted to have an analog XPath to access the array elements.
Something like:

?php

$array = ['x' = ['p' = ['a' = ['t' = ['h' = 'value'];
$xpath = ['x', 'p', 'a', 't', 'h'];
$value = $array[...$xpath];

var_dump($value); // string(5) value

?

This is certainly a topic for another RFC, but this functionality will be
useful in PHP.

Re: [PHP-DEV] [RFC] Additional splat operator usage

[S.A.N]

 That would be quite confusing, we don’t allow $array[‘x’, ‘p’, ‘a’, ’t’,
 ‘h’] just now.
 Andrea Faulds


Yes, I know, but it would be convenient, maybe someone will offer the best
option syntax.

Re: [PHP-DEV] [RFC] Additional splat operator usage

[S.A.N]

What would happen if some key from `$xpath` is undefined on the
 multidimensional `$array`?


Notice:  Undefined index...
Return NULL.

Re: [PHP-DEV] New Standardized HTTP Interface

[S.A.N]

Me as a user and developer PHP RESTful, enough auto filling the global
variable.
Make an abstract variable names (_BODY or _FORM), and filled with the value
in all the HTTP methods.

Perhaps it makes sense to do lazy loading of data in these variables, it is
simply done through an ArrayAccess interface to $_FORM variables were the
objects that implement the interface to access an array when you first
access the Elements massif, to parse HTTP message body

Your effort is better spent on creating an interface of the PHP as a demon
when Launched PHP script handles the HTTP requests.


2014-11-06 0:29 GMT+02:00 Sherif Ramadan theanomaly...@gmail.com:

 I'm not keen on the idea of adding more superglobals to PHP, although I
 certainly understand the grave concern of breaking people's code and as
 such I've chosen not to pursue the idea of removing superglobals.

 I will, however, revisit the idea of exposing the underlying SAPI
 callbacks, for handling the incoming HTTP request in PHP, to userland. From
 a rough skim through the code, so far, it appears that this is already
 entirely possible and shouldn't be very difficult to expose the SAPI API to
 userland without breaking BC. This would make it possible for people to
 register request handlers in the same way they can register autoloaders and
 as such make it possible to handle things like PUT/MOVE/PROP FIND HTTP
 requests through some custom callback.

 The only concern there is would people prefer to use their own custom
 callbacks in userland or would they prefer for PHP to do it for them?

 From all the people I've spoken with that have a problem with handling PUT
 requests in PHP, it seems that they'd rather have PHP populate
 $_FILES/$_POST automatically in this case. Which would be relatively easy
 to do by modifying the default post reader function in the SAPI
 http://lxr.php.net/xref/PHP_5_6/main/php_content_types.c#51 however, that
 is itself a small BC break.

 Does anyone have any recommendations on what they think the best approach
 is? I'd appreciate any feedback/suggestions/constructive-criticism. Thanks!



 On Mon, Nov 3, 2014 at 7:08 AM, Patrick ALLAERT patrickalla...@php.net
 wrote:

  2014-10-30 19:23 GMT+01:00 Sherif Ramadan theanomaly...@gmail.com:
   Hello Internals,
  
   I've been meaning to write up a full-blown RFC for introducing a new
   standardized HTTP interface for PHP core for some time now. I figure
 now
   with PHP 7 on the road map this might be a good time to start this
   discussion since it involves breaking some backwards compatibility that
  may
   have been out of the question in PHP 5.
  
   I've started a draft RFC, but please be patient as this is a working in
   progress, here https://wiki.php.net/rfc/http-interface on the wiki.
  
   The point here is to allow users to implement their own HttpRequest and
   HttpResponse classes that can deal directly with the raw
 request/response
   messages in any way the user deems fit. This alleviates cases like
 what
   about when I want to have $_PUT or $_DELETE and removes the ambiguity
 of
   the $_POST, $_GET superglobals to a more conforming way of handling the
   messages.
  
   Since it's an interface, it only dictates the facilitation of PHP's
   built-in functionality and the user's desired implementation, but no
 the
   implementation itself. To remove all confusion, consider the way an
 HTTP
   message actually looks.
  
   GET /foo?bar=1 HTTP/1.1
   Host: foobar.com
  
   baz=2
  
   Instead of treating this with current $_GET, $_POST, let's consider
 for a
   moment how we might treat it in an HttpRequest object:
  
   If the HttpRequest class implements an HttpParameters object that
 parses
   and treats the entire HTTP request line as a string of parameters we
  could
   accomplish the following...
  
   var_dump(HttpRequest::$parameters-bar); // int(1)
   var_dump((string) HttpRequest::$parameters); // string(6)?bar=1
  
   Now consider how the body can be treated...
  
   echo HttpRequest::$body; // baz=2
   echo HttpRequest::$body-baz; // 2
  
   Since the HttpRequest object can lazily parse the body it can also
 lazily
   apply custom filters directly to the request variables and
 parameters...
  
   For example, say you wish to treat baz only as an integer? This can be
   easily accomplished by setting the filters directly in the HttpRequest
   object and upon access the filter is directly applied to chosen
  variables.
   This also alleviates the need to worry about overwriting superglobal
   variables or having to copy from them. So from an efficiency
 stand-point
   this approach works much better. It also allows you to separate clearly
   between HTTP request parameters and HTTP request body as well as the
 HTTP
   request method. Since the request object should be capable of handling
   callbacks for each method to apply different sets of filters or rules
 on
   treating the request body given different request methods this could
  prove
   a lot 

Re: [PHP-DEV] Annotation PHP 7

[S.A.N]

If this is difficult, you can do in PHP 7.0 simple realization
annotation/facades, in versions 7.x to develop and refine.

Most importantly, define the syntax and semantics annotation/facades, for a
version of PHP 7.0

Demand in annotation/facades is very high, ~80% of all popular frameworks
their use, it is really what you need PHP developers.

2014-11-04 20:27 GMT+02:00 Stas Malyshev smalys...@sugarcrm.com:

 Hi!

  The approach for annotations that I like best would actually be not
  annotations, but Python-style decorators. They’re very simple, but
  very powerful. They would allow you to do annotations, but also add
  extra functionality to functions.

 For python-style decorators, at least the way they work in Python, we'd
 need to organize our function tables differently, as Python just
 replaces the function with another one while decorating, and I'm not
 sure it'd be as easy to do with PHP.

  Which would be equivalent to the following PHP code:
 
  $myfunc = function myfunc() { # function source code here }; $myfunc
  = some_decorator($myfunc, foo, bar);

 Not really, because functions work differently in Python and in PHP. You
 can not just replace a function in class's function table with random
 closure in PHP, at least easily.
 You'd have to convert all such functions to closures (or something that
 can be both, maybe) and have the engine be aware that function table now
 can store closures. And, also, inheritance may get a bit weird there. It
 would be very powerful, but it may not be very simple to do.

 Also, it is a major overkill for what annotations are commonly used -
 attaching a piece of data to an entity. In Python, decorators are very
 powerful for modifying function behavior (i.e., attaching pre/post
 conditions to functions or doing some things phpunit does is really
 easy) but it is too much for just attaching data.
 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] Annotation PHP 7

[S.A.N]

Nothing magical in the annotations no, they very obvious.
It gives you the to declare logic and meta data.
I do not like annotated in comments, I like the implementation of
annotation in C#

2014-11-04 0:49 GMT+02:00 Levi Morrison le...@php.net:

 On Mon, Nov 3, 2014 at 10:39 AM, Larry Garfield la...@garfieldtech.com
 wrote:
  On 11/3/14, 10:37 AM, Stefan Neufeind wrote:
 
  On 11/03/2014 05:26 PM, Pierre Joye wrote:
 
  On Nov 4, 2014 1:24 AM, Jonah H. Harris jonah.har...@gmail.com
 wrote:
 
 
  On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright c...@daverandom.com
 wrote:
 
  There are no current concrete plans and currently nothing being
 
  seriously
 
  discussed (at least, not publicly; I don't know if anyone has
 anything
 
  in
 
  pipeline that they haven't announced yet). The three RFCs you linked
 
  above
 
  are all basically dead.
 
  You are of course welcome to put together a proposal and/or start up
 a
  discussion on the subject if it is something you would be prepared to
 
  put
 
  work into.
 
 
  I, for one, severely dislike annotations. But, that's why there's an
 RFC
  process :)
 
 
  I tend to think it is not a taste matter anymore. Symfony ecosystem
  (components, doctrine and co), Zend framework, etc use them. We see
  requests to work around user land implementation but we keep us away to
  get
  native support. Maybe it is time to the jump and get rid of our tastes,
  like years ago when we discussed which kind of OO we wanted in php. At
  the
  end of the day we do what we did not want back then.
 
 
  The TYPO3-family (TYPO3 CMS, Flow, Neos) also use annotations.
  So, yes it is used in the wild already and is there to stay. We can
  imho just make it a bit easier to work with (maybe also performance-wise
  in some cases) etc.
 
 
  Kind regards,
Stefan
 
 
 
  Drupal is now using annotations as well; not for the Symfony code we've
  inherited, actually, but for some home-grown systems for which we're
 using
  Doctrine's annotation library.
 
  Having first-class language support for metadata on definitions would be
  quite helpful, if for no other reason than native syntax checking and
 code
  assistance.  (And to help people get over the it's code in comments!!!
  problem, which is entirely because we have to put annotations in comments
  now as a hack due to the lack of native support.)

 Whether the annotation is in a comment or not, the idea of changing
 behavior at runtime based on the annotation is pretty magical. I
 highly discourage using this type of feature whether it's in a comment
 or not.

 I will certainly vote no on any RFC on this subject, as I see it as
 being significantly more harmful than helpful.

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