Re: [PHP-DEV] Re: [RFC] Readonly properties

[André Rømcke]

> Yes, this is a possible alternative interpretation of the readonly concept. 
> The current proposal is closer to how Java final variables work, which never 
> allow reassignment, while your suggestion is closer to C# readonly, which 
> does allow reassigning in the constructor.
>
> I went with the current proposal, because it integrates nicely with the 
> initialization concept introduced by typed properties. At the time, we also 
> had lots of discussions about how typed property initialization should work, 
> and requiring that all typed properties be initialized by the end of the 
> constructor was one of the contenders. However, we ultimately decided against 
> such an approach, because it does not integrate well with other aspects of 
> the language. In particular we need to have the ability to initialize an 
> object while bypassing the constructor, and we don't have the ability to 
> determine initialization statically, so an uninitialized state would have 
> been required in any case.
>
> If we had gone with that alternative initialization model at the time, then 
> we would also use the same one for readonly properties. But that's not how 
> things work now. Doing something like this now would require introducing an 
> entirely new scoping concept. This brings up awkward questions like: How do 
> you bind a closure to this new "initialization scope"? Closure rebinding is a 
> common way to bypass visibility restrictions. What happens if you want to 
> call a helper method to do the initialization, does that still count as 
> initialization scope? What if you call $object->__construct() directly, will 
> that allow changing properties?
>
> The current proposal tries to provide a simple, absolute guarantee: Once 
> initialized, the property will never change again. I think that makes the 
> feature easy to understand and reason about.


Thanks for the detailed explanation, I'm sold!
And it seems it can evolve further once complementary features are introduced.

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

Re: [PHP-DEV] Re: [RFC] Readonly properties

[André Rømcke]

> > It's okay to vote against this if cloning is a deal breaker. In that case
> > I'll probably either work on cloning before re-proposing this, or pivot to
> > asymmetric visibility -- it's not my first preference, but it may be the
> > more pragmatic choice. Cloning is definitely the weak point of this
> > proposal.
>
> I already went through the clone-arguments mental exercise in my earlier 
> analysis, and the code
> it produces is totally disgusting. :-)  clone-with is a considerably better 
> approach if you're starting
> from readonly.  (It's also better if you start from asymmetric visibility, 
> although that version needs
> a clone-help feature far less.)


Internals have been here before, it's a recurring problem in PHP that
fundamentally missing features are voted down because people want
other complementary features first.

read only has been voted down by people rather wanting type properties
first, or rather wanted assessors first. And then in turn accessors
multiple times were voted down by the other 2 camps. But these
features are interconnected and need to be done step by step, during
the process things won't be perfect either way,

Now we have read only vs clone with vs accessors vs ...

IMO problem caused by no clear roadmap / vision of the project that
people can be united behind.

--

Anyway, even though I tried to push for asymmetric visibility last
year I'd gladly vote +1 on this.
It's not perfect, but it's the right direction, and there are multiple
starting points to get there.

This solves 80-90% of the use cases out there for read only
properties, which is a very good start.

--

Nikita: Probably a small thing, but the only detail I'm unsure of is
why focus on write-once logic? Why not aim for aligning it with a
future *:init visibility, where I would think the property in PHP
should be writable in __construct(), __destruct() and __clone().

This won't solve the separate clone with feature request. But it would
make it more flexible and language design wise would set it up for
possible asymmetric visibility + init option later.

For now it would at least allow setting default values on the
property, for instance if argument to constructor is not 1 to 1 with
property type/value and needs some light logic in __construct to
determine if property should be set to something else then default.

But again, don't see a blocker here in current RFC, as it starts out
with a narrow scope of read only, and this can be widened later.

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

Re: [PHP-DEV] [RFC] Property write visibility

[André Rømcke]

>
> ergonomic, and in the case of magic method usage improve performance.
>>
>
> I think this is a good direction to explore, but would recommend delaying
> it until PHP 8.1. As the RFC and discussion note, the design space here
> overlaps significantly with both readonly/immutability and property
> accessors. We should take enough time to consider these
> alternatives/extensions as well, to ensure that we don't end up with
> multiple distinct and possibly incompatible mechanisms. We don't have that
> time before PHP 8.0 feature freeze.
>


I've updated the RFC to rather aim for 8.1, I fully agree this should in
any form be made asure to align well with the related requests. Larrye's
email is a good example of what kind the language might look like when
several such features are potentially accepted in the future.

May I propose that some of us interested in this do a short call over the
summer on this topic to see if we can align on direction?

Re: [PHP-DEV] [RFC] Property write visibility

[André Rømcke]

>
> I think the only thing worth mentioning where references are concerned is
> that "$x =& $this->prop" is considered a write of $this->prop, not a read,
> so it is subject to the write visibility. But once the reference is
> acquired, visibility no longer factors into the behavior.
>
>

Ok, thanks!
So instead of   : "Attempting to pass a property value outside of allowed
writable scope as a reference, results in an error."
Instead maybe: "Assigning variable by reference is subject to write
visibility, meaning ''$x =& $this->prop'' is considered a write of
$this->prop, not a read" ?

Re: [PHP-DEV] [RFC] Property write visibility

[André Rømcke]

>> "Attempting to pass a property value outside of allowed writable scope
>> as a reference, results in an error."
> 
> ... we definitely shouldn't do this, because it goes against existing 
> language semantics. You can take a reference to a normal private property 
> (i.e. private get, private set), pass it outside the class and then modify it.



This was copied from some other source actually. I’m all for staying as close 
as possible to how the language behaves on this, changing it should be 
different RFC.

Should I just remove this section or do you have suggestions for what we need 
to specify when it comes references?

Re: [PHP-DEV] [RFC] Property write visibility

[André Rømcke]

> Perhaps another option could be to use attributes:
>
>  <>
>  public int $id;


I’d actually also like a syntax like that as well for ReadOnly and
Immutable in the end.
It's more readable and it would be possible to annotate on the class level
as well (to affect all properties).

So I initially explored* in this direction, however if we go that way first
we'll likely end up with any reflection code
having to deal with attributes and understand their underlying visibility
semantics.

If we rather go this route of first introducing the concept of disconnected
visibility. The reflection API is
far clearer / understandable, more future proof, and adding the attributes
as immediate syntax sugar
followup is far more straightforward.

* initial explorative draft rfc:
https://wiki.php.net/rfc/readonly_and_immutable_properties

Re: [PHP-DEV] [RFC] Property write visibility

[André Rømcke]

>
>
>> I agree that there is a use case for it, however I don't think the
> proposed syntax `public:private` is intuitive. Maybe we can come up with
> something better?
>

Would something closer to Swift be better? If so I expanded the RFC with
that syntax option as well:

class User {
public private(set) int $id;
public protected(set) string $name;

public function __construct(int $id, string $name) {
$this->id = $id;
$this->name = $name;
}}

Re: [PHP-DEV] [RFC] Property write visibility

[André Rømcke]

man. 29. jun. 2020 kl. 12:06 skrev Deleu :
> Are there any other languages that have a similar syntax? Has any other
language syntax been considered

The only one I could find that matches is Swift:

public private(set) var numberOfEdits = 0

https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html#ID18



Beyond that there are some notable related examples:

C#

public readonly Color Black = new Color(0, 0, 0);

The semantics of readonly is closer to what we refer to as immutable here:
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#readonly-fields

If you want other semantics in C# you'll need to resort to Accessors:
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#accessors



Rust:

// This field can be read (but not written) by super.
#[readonly]
pub(super) readable: i32,

Essentially a feature using "attributes":
https://docs.rs/readonly/0.1.6/readonly/

--
Best
André Rømcke

[PHP-DEV] [RFC] Property write visibility

[André Rømcke]

Good morning Internals,

I'd like to start discussion on a new RFC proposing a way to be able to
(optionally) specify property
write visibility, separate from read:

https://wiki.php.net/rfc/property_write_visibility

This enables readonly, write-only and immutable like semantics for PHP's
properties.

These are the common use cases where users tend to resort to magic methods
or setter/getter
methods. This proposal will as such avoid unnecessary boilerplate, makes
coding easier and more
ergonomic, and in the case of magic method usage improve performance.


Best,
André Rømcke

Re: [PHP-DEV] Re: [RFC] Typed Properties

[André Rømcke]

> On 19 Jul 2018, at 13:34, Dmitry Stogov  wrote:
> 
> I've run few benchmarks, to measure the performance penalty of this proposal.
> 
> 
> https://gist.github.com/dstogov/b9fc0fdccfb8bf7bae121ce3d3ff1db1
> 
> 
> In most cases real-life apps become ~1% slower. In the worst case, I got 6% 
> slowdown (on mediawiki).


Nice overview.

Is there any overview of how it will improve performance for code moving from 
magic getters / setters to this?

Or is there interest in such a comparison?

(Context: working on a larger open source project where that is used quite a 
bit for type and read-only safety checks.)


Best,
André

Re: [PHP-DEV] [RFC] Typed Properties

[André Rømcke]

On 7 Jul 2018, at 23:13, Zeev Suraski  wrote:

>> -Original Message-
>> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
>> Golemon
>> Sent: Friday, July 6, 2018 10:36 PM
>> To: Christoph M. Becker 
>> Cc: Nikita Popov ; s...@php.net; Björn Larsson
>> ; Dan Ackroyd ;
>> Stanislav Malyshev ; Marco Pivetta
>> ; PHP internals 
>> Subject: Re: [PHP-DEV] [RFC] Typed Properties
>> 
>> Just want to be annoying about this since the currently scheduled fork date 
>> for
>> PHP-7.3 is 11 days off.
>> 1/ Do we have *ANY* objections to additional alpha(s) to accommodate Typed
>> Props? (I would propose two additional alphas) 2/ Do we actually need to 
>> hold a
>> formal vote? (If so, that vote should start *now*)
> 
> Sara,
> 
> I do see a couple of issues here.
> 
> First, it may be a personal thing, but I feel that the flexibility towards 
> adding this is very contrasty with the inflexibility shown as we headed 
> towards the PHP 7.0 feature freeze - inflexibility that resulted in a rushed 
> (and IMHO wrong) decision regarding how to implement the non-strict types.  
> For the record - as I said back then - I think that the right way is to be 
> flexible - the dates are just dates, and are - in all honesty - not that 
> important - it’s the severe inconsistency that bothers me.


Regardless of typed properties this sounds like something that should be 
tackled as an independent topic. (It could in theory, if accepted, be a new 
type flag introduced in 7.4 and made default in 8.0 that affect all type usage 
consistently.)


> 
> Secondly, and somewhat related - typed properties isn't a small feature.  It 
> is, in fact, a pretty huge one.  Making exceptions for a fairly minor feature 
> or some extra deprecation is one thing.  Making an exception for something as 
> fundamental as that feels wrong.  
> 
> Even though Nikita's proposal and implementation look pretty solid, something 
> as fundamental as that should go through a substantial active discussion 
> period (which didn't really happen here as it wasn't clear whether this was 
> headed for an exceptional 7.3 addition or not) - and independently - should 
> perhaps go hand-in-hand with fixing the flaws of the non-strict types - 
> something we can do in PHP 8.  If we do the latter, then perhaps, just 
> perhaps, we can introduce it hand-in-hand with typed variables - and if we 
> do, it will be sensible to do it at the same time and not in a gradual 
> rollout.  Personally, I think even independently of typed variables, typed 
> properties feel like an 8.0 feature, not a 7.x feature.


While I agree this is big, (from user land it’s fantastic), and should only go 
in if solid. It does contradict your argument the other day about being careful 
what to push into 8.0 scope as core resources are scarce.

So if we look at it from that perspective, then spreading the risk is 
essentially safer.

Re: [PHP-DEV] HYBRID VM

[André Rømcke]

> On 10 May 2017, at 10:53, "li...@rhsoft.net" <li...@rhsoft.net> wrote:
> 
> 
> Am 10.05.2017 um 08:21 schrieb André Rømcke:
>>> On 5 May 2017, at 22:06, Dmitry Stogov <dmi...@zend.com> wrote:
>>> 
>>> It provides comparabele improvement on smal benchmarks, without degradation 
>>> on real apps.
>>> It can be compiled in reasonale time (GOTO requres significant time anda 
>>> lot of memory).
>>> Finally HYBRID fallbak to CALL if compiler doesn't provide necessary 
>>> extensions.
>> While at it how does this compare to jit branch?
> 
> obviously it's not "one or the other"
> 
> https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit
> https://github.com/zendtech/php-src/commit/d570de2cb6a88d9772f510d112a04ce4022110cd


Already following that, but thanks for the sarcasmsplaining.

Question was more in regards to if that will follow suite, but I assume not 
(yet), and this wouldn't be the right thread for it.

Re: [PHP-DEV] HYBRID VM

[André Rømcke]

> On 5 May 2017, at 22:06, Dmitry Stogov  wrote:
> 
> It provides comparabele improvement on smal benchmarks, without degradation 
> on real apps.
> It can be compiled in reasonale time (GOTO requres significant time anda lot 
> of memory).
> Finally HYBRID fallbak to CALL if compiler doesn't provide necessary 
> extensions.

While at it how does this compare to jit branch?


> 
> Thanks. Dmitry.
> 
> On May 5, 2017 10:26 PM, Matt Wilmas  wrote:
> Hi Dmitry,
> 
> - Original Message -
> From: "Dmitry Stogov"
> Sent: Wednesday, May 03, 2017
> 
>> Hi,
>> 
>> 
>> I propose a new VM instruction dispatch technique, that provides great
>> speed up on small benchmarks (1.5 times on bench.php)
> 
> Interesting. :-) How does this compare to pure GOTO dispatch...?
> 
>> Please review https://github.com/php/php-src/pull/2507
>> 
>> Take into account, that HYBRID VM is not enabled by default and VM has to
>> be regenerated by "php zend_vm_gen.php --with-vm-kind=HYBRID"
>> 
>> 
>> It doesn't work with phpdbg, out of the box, and may make some troubles to
>> xdebug and other system extensions.
>> 
>> 
>> I'm going to commit this into master after review and then rise question
>> about enabling it by default in PHP-7.2.
>> 
>> 
>> Thanks. Dmitry.
> 
> - Matt
> 
> 

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

[PHP-DEV] Request for Karma

[André Rømcke]

Hello PHP Team,

Even if to late for 7.1, it’s summer time and I’d like to contribute to
moving forward on updating a RFC for Property Accessors Syntax
to bring that up to level of 7.x.

I’m not a C programmer so I’m interested in finding someone to co-write
this with. As for background I’m leading the teams involved in
developing and maintaining eZ Publish and now eZ Platform. Open
source CMS solutions that has PHP roots since it’s start around 2000.
I have been voting member of FIG and member of this mailing lists
for several years, and hope to find a viable solution for everyone.

For now please grant my wiki user edit access, and if any core member
would have interest in mentoring me on this, that would be great.

Username: andrerom

Best regards,
André R.

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

[André Rømcke]

> On 25 Apr 2016, at 16:36 , Rowan Collins  wrote:
> 
> 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.


As long as it’s cache is not shared among processes, rather not.
A user cache needs to be able to be shared between cli and web process to cover 
the main use cases imo.

Re: [PHP-DEV] Final properties

[André Rømcke]

> On 16 Apr 2016, at 11:19 , Lester Caine <les...@lsces.co.uk> wrote:
> 
> On 16/04/16 06:56, André Rømcke wrote:
>>>> This actually summarises many of the problems all of these 'extras' are
>>>> creating for very little gain.
>>>> 
>>>> 'Seconds' is a 'Traditional Property' so is untyped and if accessed as a
>>>> value from some OS's will be a floating point number[...]
>> It wasn't really the example I intended to point to, it does not represent 
>> the cases me and others refer to. I was linking to it for the possible 
>> solution to handle type and immutability.
>> 
>> Examples for the latter:
>> https://en.m.wikipedia.org/wiki/Value_object
> 
> Working from and SQL base ... the schema provides both validation beyond
> simply 'int' or 'float' and 'read only' all simply extensions to the
> basic variable returned.


readonly in this case is more about application logic and not db logic.
If you want to take a swing at it a more relevant example would be to just ask 
everyone to use get() and in case of writable properties 
set($value) and stop asking about expanding the language to cover the 
use cases and hence simplify use.

> 
>>>> I don't see how the idea of 'optimizing' the compiled code has any
>>>> bearing on handling a 'typed property' when one has to have an object to
>>>> contain even the simple of type information?
>> 
>> What is this regarding?
> 
> People have been claiming they need to be able to identify the type in
> order to optimize the compiled code. […..]

True, for me is more about the benefits in user land. There are lots of cases 
where those claims won’t be true, as in scalars changing types. So even with 
type hints it will still need some sort of tracing JIT compiler that uses type 
info from todays runtime to machine compile hot spots, the type hints will 
merely make sure the type is somewhat more predictable. And even then you’ll 
need to account for possible type misses and sometimes have to pop back to 
interpreter effectively loosing time. All of which Javascript has done for 
years and continue on to do, afaik latests on that is 
https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/

 
But even if discussing that would be neat, and it’s relevance since there have 
been discussions on using LLVM with PHP over the years. This thread is not 
really about type, it’s about readonly properties or whatever you would like to 
call them :)


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

Re: [PHP-DEV] Final properties

[André Rømcke]

On 14. apr. 2016, at 11.47, Lester Caine <les...@lsces.co.uk> wrote:
> 
>> On 14/04/16 08:52, André Rømcke wrote:
>> * https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
> 
> This actually summarises many of the problems all of these 'extras' are
> creating for very little gain.
> 
> 'Seconds' is a 'Traditional Property' so is untyped and if accessed as a
> value from some OS's will be a floating point number[...]

It wasn't really the example I intended to point to, it does not represent the 
cases me and others refer to. I was linking to it for the possible solution to 
handle type and immutability.

Examples for the latter:
https://en.m.wikipedia.org/wiki/Value_object

> 
> I don't see how the idea of 'optimizing' the compiled code has any
> bearing on handling a 'typed property' when one has to have an object to
> contain even the simple of type information?


What is this regarding?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final properties

[André Rømcke]

> On 14 Apr 2016, at 00:36 , Stanislav Malyshev  wrote:
> 
> With getters/setters, the answer is clear - yes, you can extend it with
> setters, but if your invariant relies on immutability, you'd be
> violating LSP. With properties, not clear.


So in summary preference would be that something like Property Accessors 
Syntax* is re opened and updated?

>From user land main motivation to support this and typed properties is to be 
>allowed to type hint and make properties readonly to simplify use cases for 
>entities and value objects, using properties, and not having to resort to 
>magic methods which tends to become slow(er) and messy. For how this is 
>archived, not violating LSP, and making sure the language and internals are 
>kept as consistent as possible would be high up there as reasoning to pick 
>approach



* https://wiki.php.net/rfc/propertygetsetsyntax-v1.2


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

Re: [PHP-DEV] Final properties

[André Rømcke]

> On Apr 11, 2016, at 06:59 , Larry Garfield  wrote:
> ...
> (Which leads to "can interfaces define properties", which leads right back to 
> "well what can you do with them", which leads back to the Properties RFC. 
> Which I still want to see happen at some point if at all possible, as it 
> would also subsume this question quite nicely.)
> 

And by Properties RFC you mean Property Accessors Syntax RFC right?
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2


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

Re: [PHP-DEV] Final properties

[André Rømcke]

> On Apr 9, 2016, at 09:39 , Sebastian Bergmann  wrote:
> 
> Am 05.04.2016 um 11:13 schrieb Marco Pivetta:
>> First of all: +1 to this: very useful for value objects!
> 
> My thought exactly.


Big +1 on this feature for the exact same reasons.

> 
>> do we want to use `final`, or `immutable` for these properties?
> 
> I have the same sentiment you have, that "final" would be confusing
> and "immutable" would be better. But it's also confusing to have
> the same concept another language has under a different name. Hm.
> 
> I think I tend towards "immutable".

I tend to as well. However as noted on misc C# pages* about immutable, this can 
be slightly confusing also; If the variable is ArrayAccess you will still be 
able to call offsetSet on it. “readonly"** would be another option, even if 
some might assume class can always write to it.

Since there is no perfect name, maybe let the name be open for vote as part of 
RFC? To avoid to much focus on the naming during discussions/specification?

* http://stackoverflow.com/a/6849164
** https://msdn.microsoft.com/en-us/library/acdd6hb7.aspx

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[André Rømcke]

 On Mar 17, 2015, at 18:04 , Leigh lei...@gmail.com wrote:
 
 On 17 March 2015 at 08:37, Lester Caine les...@lsces.co.uk wrote:
 
 To help towards that end, can someone who understands what is wanted
 from the weak type hint mode actually produce a summary of that as it is
 very difficult to extract just what has now been agreed for that area of
 type hinting. A base that can be used to review some of the other
 discussions to put that to bed. Others might appreciate a similar
 summary of the 'type_error' mode as well? As a base for the
 documentation on the user manual updates?
 
 
 Not sure what is difficult to extract
 
 https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks
 
 It's all right there...


That part answers what has been agreed (or rather accepted), but not who the
weak mode is for, and why.

Tried to sum that up last week when there was still discussions on this:
http://share.ez.no/blogs/core-development-team/php-7-sth-from-user-perspective

TL;DR;  weak mode is for api consumers, aka normal php users, while strict is
 for the actual target users of this features: api (library/framework) creators.

Post also argues for why Zeev's adjustments to weak sth handling should still
be done, as well as arguing for disallowing/fixing closure hint in strict mode.


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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[André Rømcke]

Congratulations Antony, Andrea and (yes) Zeev!
Thanks to everyone involved, this is a great step forwards and a perfect wrap 
for PHP 7.0 RFC proposal freeze :)


André


 On Mar 16, 2015, at 23:05 , Chris Harvey ch...@chrisnharvey.com wrote:
 
 Congratulations Anthony, and to Andrea for her initial proposal.
 
 Finally, we have scalar type hints in PHP.
 
 PHP 7 is going to be a real game changer!
 
 Chris
 
 On 16 Mar 2015, at 9:03 pm, Anthony Ferrara ircmax...@gmail.com wrote:
 
 All,
 
 Voting has been closed on the scalar type declarations v0.5 RFC:
 
 https://wiki.php.net/rfc/scalar_type_hints_v5
 
 At a final score of 108:48, it has been accepted for PHP 7.
 
 Thank you.
 
 Anthony
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

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

[André Rømcke]

On 09 Feb 2015, at 19:24 , guilhermebla...@gmail.com wrote:
 
 Hi Andrea,
 
 I totally see your viewpoint. That's why initially I voted YES, because
 your proposal somehow makes sense.
 My when I thought over and use a weak/strict boolean type conversion on my
 own brain, I came to the conclusion my real wish does not get fully
 addressed with a YES, leading me to switch my vote.
 I really wanted to expose the motivation of my change here, so everyone is
 aware that I do love strict typing, and I really want this in for PHP, but
 not in this RFC way.


To me this is the best compromise that can be made here.
In case of boolean: if you specify boolean, boolean is what you get, no matter 
what user of your library do.

So you are in full control here!
You are not, however, in control over other peoples code, which you shouldn’t 
be anyway. After all you didn’t write it.

The RFC quite elegantly allows both strict and weak camps to be pleased, 
bikeshedding on declare() aside.
So it is a pity people in those camps don’t see that, as this is rather 
overdue* feature.


Best,
André


* It is a feature that allows us all to write more reliable, shorter, and 
better self documented code.
  We got it for all other types up until now, only scalars missing.

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

[André Rømcke]

 
 On 02 Feb 2015, at 17:35 , Derick Rethans der...@php.net wrote:
 
 On Mon, 2 Feb 2015, Dmitry Stogov wrote:
 
 As I already told, in my opinion, version 0.1 was the perfect solution that
 fit into PHP semantic very well.
 
 declare(strict_types=1); - is really weird solution.
 It changes type hinting behavior per file scope, so, just to try strict
 type hinting in a big project, people will have to change every single PHP
 file.


declare() might not be beautiful, but it is pragmatic as it already exists.
As for full project switch, can’t we easily do a followup RFC with a command 
line flag/ini setting to run unit tests in strict mode for instance?

 
 THis is why I believe it makes more sense to have this switch on the 
 callee side, instead of on the calling side.


I’m not sure I see why that would make more sense.
On the callee side what you get is strictly what you asked for anyway, no 
matter what mode on the calling side. 

This is the true beauty of what Andrea has come up with here, allowing weak PHP 
like forgiveness to co-exists with opt in for strict behavior.


Best,
André

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

[André Rømcke]

On 09 Feb 2015, at 16:04 , Sebastian Bergmann sebast...@php.net wrote:
 
 Am 09.02.2015 um 15:50 schrieb Pierre Joye:
 Not strict? You loose me here.
 
 I want support for scalar types in signatures. I want these type
 declarations to be strictly enforced. This is not wanted and not
 proposed by the RFC. Hence my vote.


It is, from your point of view, the provider of a API, strictly enforced: 
you’ll get exactly the type you asked for.
The current RFC is clever in this way, it makes sure the library author gets 
the types they want, and the user of it can freely choose mode as he see fit 
and is skilled for.

I’m sure we can easily do a followup RFC to add a ini setting/argument, to be 
able to run unit test in strict mode by default, unless for instance code 
specifically declares strict_types=0.
Which I guess would be great for PHPUnit runs to really get full control over 
what kind of types we use throughout our code.

So to summarize: This RFC gets you a ton of a lot closer to the strictness you 
(and I), would like to use for at least our test runs..


Best,
André

Re: [PHP-DEV] Wake up

[André Rømcke]

On Sep 11, 2013, at 15:52 , Terence Copestake terence.copest...@gmail.com
 wrote:

 (.. ) a concern
 brought up repeatedly both here and in various blogs is the lack of
 direction or vision. There's a conflict between people who want to keep PHP
 simple and accessible and people who want to make PHP into a professional
 programming tool/environment, complete with all bells and whistles. With
 everyone wanting something different and having different ideas on who the
 target users are, what PHP's responsibilities and concerns should be, etc.,
 it's going to be the classic struggle of trying to be everything for
 everybody all at once.


Won't solve the perceived lack of vision, but the conflict could potentially be 
solved by modeling php language standardization after how they do it at Ecma, 
w3c or iso.
For instance: Let php-internals be as is, Internal stuff in PHP engine and 
announcements of rfc's for it, but move out the organization of standardizing 
the language.

1. The people involved in standardization should be representatives of the 
different implementations of PHP language.
2. Accepting changes to the language would requirer that at least one 
implementation have it working behind a compile/runtime flag*
3. Language Tests should be shared and be part of the standardization effort
4. The PHP language standardization body should always allow some variation on 
how much a implementation helps the user by default

# Example: Argument and return type hinting**

Specification on this can define two modes of operation:
1. Fatal error on wrong type
2. Strict error on type conversion, and Fatal error on type conversion 
with data loss

HPHP could then use mode 1 by default, while PHP uses 2 by default (and 2 
with strict errors disabled in production).

This was not intended as a flame, best regards
André R.
eZ Systems



* For anyone involved in web development you might know how messy css vendor 
prefixes made the web, forcing them to be behind compile/runtime flags would 
avoid this
** Just an example, ignore the details please
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6 : a new API ?

[André Rømcke]

On Feb 20, 2013, at 11:19 , Sebastian Krebs krebs@gmail.com wrote:

 2013/2/20 Klaus Ufo klaus...@yahoo.fr
 
 Hi there !
 
 We all know that the current PHP API has flaws. Maybe we could use
 namespaces to build a new coherent PHP API ? Like :
 
 - \arr
 - \num
 - \str
 
 and so on. Advantages :
 
 - no more global functions
 
 
 Just to throw that in: Even if you pack them into namespaces they will
 still remain global functions. They simply don't live in the root-namespace
 anymore.


+1

So why not avoiding this by adding it as methods of the scalar variable 
instead, aka autoboxing.
This would allow the new api to be closer to what people are used to from other 
languages, needs far less typing and IDE autocomplete of available functions pr 
type with -.

More recent example by Nikita Popov, see unit tests of the project for examples:
https://github.com/nikic/scalar_objects/blob/master/tests/string.phpt#L17


 
 
 - separation of concerns
 - backward compatibility
 
 - work can be done progressively
 - easy to add user-defined functions (using php namespaces)
 - we could provide a \str\utf8 namespace
 
 This is just an idea. I don't know what is your vision for a next PHP 6.
 
 KH
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 
 -- 
 github.com/KingCrunch



--
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

[André Rømcke]

On Feb 18, 2013, at 23:03 , Christopher Jones christopher.jo...@oracle.com 
wrote:

 
 
 On 02/18/2013 10:52 AM, Christopher Jones wrote:
 
 I agree that unless we get Gopal-like inspiration (inclued, scream) for 
 naming, opcache is best.
 
 In the so bad I can't resist sending it category is today's
 semi-humorous name suggestion: Cajun.  It sounds roughly like the
 English pronunciation of caching
 
 Sadly it's not as nicely self-documenting as opcache.
 


opcache is fine, its better that it's self describing then exiting.


not:to-be-taken-seriusly
Cause then you don't have to google it to figure out what it is every time,
like T_PAAMAYIM_NEKUDOTAYIM :P

So if you really have to make a name for it, keep it self describing, like: 
OpsiCache
Other then already being a used name, ops(i) is the word you would say in some
languages when you realize you have done a mistake :)
/not:to-be-taken-seriusly

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

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[André Rømcke]

On Oct 11, 2012, at 4:59 AM, Clint Priest cpri...@zerocue.com wrote:

 Why is everyone so dead set against read-only and write-only?
 
 I could not disagree more with you on what is pretty and readable.
 
 To me:
 
 public read-only $hours {
get { ... }
 }
 
 Is infinitely more readable and understandable than:
 
 public $hours {
get() { ... }
private final set($value) { ... }
 }
 
 The latter implies that it can be set within the right context (internally 
 to the class), which is precisely the opposite of what is desired (read only).


If it can be used on normal properties as well (w/o the overhead of function 
calls) then: +1
Otherwise it would not be consistent to introduce it.

On the topic of consistency, could not see any other keyword in php that uses 
hyphen in it.


 
 From: Jazzer Dane [mailto:tbprogram...@gmail.com]
 Sent: Wednesday, October 10, 2012 9:18 PM
 To: Clint Priest
 Cc: internals@lists.php.net
 Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
 
 This all sounds about right.
 
 In regards to #4 - read-only/write-only:
 I think that, from a pretty syntax point of view, private final set() {} 
 and private final get() {} are definitely our best bets. But... from a 
 logical point of view, I prefer read-only/write-only.
 
 private final get() {} is technically saying it will always return null.
 private final set() {} is technically saying that setting doesn't do anything 
 - but it still works.
 
 But I don't see any sane scenario where someone would want to do the above. 
 Therefore, it may just be best to use them in place of the currently proposed 
 read-only/write-only.
 On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest 
 cpri...@zerocue.commailto:cpri...@zerocue.com wrote:
 Okay, I would like this to be the last time there are revisions to this RFC.
 
 To sum up the last few days of conversations, I have these down as points of 
 contention:
 
 1.  Accessor functions should not be present on the object and callable 
 directly, for example, $o-__getHours() should not be allowed.
 2.  Preferred syntax for accessors should be public set($value) { ... } 
 with no magic $value (with possible type hinting)
 3.  Automatically implemented get; set; with auto-backing field should be 
 eliminated as this is not necessary for PHP and is confusing most everyone.
 4.  read-only / write-only keywords, keep them or get rid of them?  There is 
 no directly suitable replacement but I believe a private final set() { } will 
 take care of it, even though it much more verbose.
 5.  Error handling for thrown exceptions should be made more appropriate for 
 accessors
 6.  The truth of reflection.  Should it reveal details internal to how PHP 
 works on the inside or should it reflect the way PHP presents it as options?
 
 Did I miss anything?
 
 
 I will come up with some way for people to vote on the issues at hand and we 
 can cast our votes and be done with it, then I will finish the project and 
 get it out the door.
 
 -Clint
 



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

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[André Rømcke]

On Oct 8, 2012, at 10:07 PM, Denis Portnov denixp...@gmail.com wrote:

 08.10.2012 15:52, Clint Priest пишет:
 public $Hours {
 get { return $this-Seconds / 3600; }
 set { $this-Seconds = $value; }
 issethttp://www.php.net/isset  { return 
 issethttp://www.php.net/isset($this-Seconds); }
 unsethttp://www.php.net/unset  { 
 unsethttp://www.php.net/unset($this-Seconds); }
 }
 
 
 Hi Clint,
 
 I've noticed some magic variable '$value' is introduced. And except for 
 superglobals I guess there is no such thing in PHP, so it looks bit puzzling 
 to me. I'd suggest on of the following:
 
 - variable for value has the same name as property
public $Hours {
set { $this-Seconds = $Hours * 3600; }
}
 
 - magic constant
public $Hours {
set { $this-Seconds = __VALUE__ * 3600; }
}
 
 - setter resambles setter method, wich also allows typehinting
public $Hours {
set ($value) { $this-Seconds = $value * 3600; }
}
 
public $Hours {
set (DateTime $dateTime) { $this-Seconds = $dateTime-getTimestamp(); 
 }
}


If this function inspired syntax is used, then it kind of hints the possibility 
of future parameter overloading, like:

public $Hours {
set ( DateTime $dateTime ) { $this-Seconds = $dateTime-getTimestamp(); }
set ( int $hours ) { $this-Seconds = $hours*60*60; }
}


So for me +1 on that syntax, or using/future-proofing for the syntax from C#:

public DateTime $Hours {
set { $this-Seconds = $value-getTimestamp(); }
}

However the example doesn't make much sense (hours being datetime).


 
 - or at least have it in same format as superglobals
public $Hours {
set { $this-Seconds = $_VALUE * 3600; }
}
 
 What do you think?
 
 Thanks
 Denis
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 

Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces

[André Rømcke]

( resending with correct formatting, and missing context while at it, sorry 
about that )

On Aug 15, 2012, at 8:33 PM, Nikita Popov wrote:

 (...)
 
 Another aspect here is that there is no reasonable syntax for this
 feature, at least I can't think of one:
 
 * The syntax `$foo = (InterfaceName) $container-service` is
 completely out of question. It looks like a cast, but wouldn't
 actually do a cast.
 * Same is to be said about `InterfaceName $foo =
 $container-service`. This syntax implies that the $foo variable will
 always be of type InterfaceName, even if it is later reassigned. It's
 not a sensible syntax for a one time validation
 * The other three syntaxes that were mentioned were just as unclear.
 E.g. `$foo = $container-service as InterfaceName` again looks like a
 strange cast syntax and `$foo = $container-service is InterfaceName`
 looks like the assignment should evaluate to a boolean (i.e. `is` is
 some kind of `instanceof`).


good points
In addition, the root cause that triggered this proposal in the first place: 
serve container / object registry doc issue, is kind of moot, ref bellow.


 
 On the other hand, the current ways of accomplishing the same goal are
 well-established and easy to understand:
 
 * Using a docblock: /** @var $foo IntefaceName **/
 * Using an assertion: assert($foo instanceof InterfaceName).
 
 I think that the assertion is a rather concise and clear way to do
 this. It is much more obvious than some new and obscure `$foo =
 (InterfaceName $container-service)` syntax.



To expand on that, @Stan: If you make sure you configure your container to 
injection dependencies (and in case of lazy loading, inject factories* with 
type hinting in doc) instead of passing the [dependency injection] container 
around as a registry, then you almost don't get this problem at all, and you 
will avoid introducing container awareness/dependency in your architecture.

Only place you will have this original problem though is in the code that gets 
the first dependency of the execution, like in index.php for instance, but even 
then you can have Container interface for the most common root dependencies.
In the cases that doesn't fit, you should plainly use the doc block referred to 
by Nikita, it is already supported by IDE's and won't need additional 3 years 
to get support.


* As alternatives to factories with or without container knowledge, there is 
one alternative that some containers support:
  Proxy objects: container generates proxy objects whenever you want 
dependencies to be lazy loaded, they have container awareness, but this becomes 
100% transparent to your code, but it probably adds some overhead.

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

Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces

[André Rømcke]

On Aug 15, 2012, at 8:33 PM, Nikita Popov wrote:

On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig 
kris.cr...@gmail.commailto:kris.cr...@gmail.com wrote:
On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara 
ircmax...@gmail.commailto:ircmax...@gmail.comwrote:

Stan,

On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass 
sv_for...@fmethod.commailto:sv_for...@fmethod.com wrote:

Hi!

I agree with you. The one case where this syntax may be very useful is
if
we want to implement class casting. So introduce a pair of magic
methods


I do not think we want to implement class casting. I'm not sure how
class casting even makes sense - if the object is of one class, how can
you just make it into another class by casting? If you mean casting
actually returns another object of different class, then just make a
method for that that returns that object, I do not see how obscuring the
purpose of this operation with unobvious syntax would help.


The discussion is starting to drift very far from my original proposal.

Instead of trying to guess what I mean, can't people just refer to my
very
simple definitive proposed behavior?


My point was that what I posted was the only way that I can see for the
original proposal to be useful.

Anthony


Though I'm clearly in the minority on this, I for one think this proposal
does have more merit than is being argued.  There seems to be general
agreement all around that this would provide a benefit as it pertains to
code readability-- Not just by humans, but theoretically by doc/etc parsers
as well.

This is where we get into arbitrary, subjective territory.  To me, that
benefit in and of itself is sufficient to warrant this feature.  To many of
you, it is not enough.

The tie-breaker for me is the fact that, though the benefits are modest,
there's really no noticeable cost, either.  The argument seems to,
essentially, break down as follows:  This feature isn't worth our time.
 Yes, it is!  No, it isn't.

Every feature has a cost, even if that cost is just maintaining the
code. Doing language changes for minority use cases, which already
have sensible solutions, doesn't make much sense.

Another aspect here is that there is no reasonable syntax for this
feature, at least I can't think of one:

* The syntax `$foo = (InterfaceName) $container-service` is
completely out of question. It looks like a cast, but wouldn't
actually do a cast.
* Same is to be said about `InterfaceName $foo =
$container-service`. This syntax implies that the $foo variable will
always be of type InterfaceName, even if it is later reassigned. It's
not a sensible syntax for a one time validation
* The other three syntaxes that were mentioned were just as unclear.
E.g. `$foo = $container-service as InterfaceName` again looks like a
strange cast syntax and `$foo = $container-service is InterfaceName`
looks like the assignment should evaluate to a boolean (i.e. `is` is
some kind of `instanceof`).


good points



On the other hand, the current ways of accomplishing the same goal are
well-established and easy to understand:

* Using a docblock: /** @var $foo IntefaceName **/
* Using an assertion: assert($foo instanceof InterfaceName).

I think that the assertion is a rather concise and clear way to do
this. It is much more obvious than some new and obscure `$foo =
(InterfaceName $container-service)` syntax.



@Stan: If you make sure you configure your container to injection dependencies 
and in case of lazy loading inject factories with type hinting in doc istead of 
passing the [dependency injection] container around as a registry, then you 
almost don't get this problem at all, and you will avoid introducing container 
awareness/dependency in your architecture.
Only place you will have this original problem though is in the code that gets 
the first dependency of the execution, but even then you can have Container 
interface for the most common root dependencies. Like: 
https://github.com/ezsystems/ezp-next/blob/master/eZ/Publish/API/Container.php



Nikita

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

Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility

[André Rømcke]

On 7/23/12 12:38 PM, Amaury Bouchard 
ama...@amaury.netmailto:ama...@amaury.net wrote:

2012/7/23 André Rømcke andre.rom...@ez.nomailto:andre.rom...@ez.no
I think these two proposals can be synced up, what if:

public readonly $a;

Is shorthand for:

public $a { get; protected set; }


And when no function is defined, no function overhead is added.

Well, this code:
public read-only $a;
introduces a new keyword (that should be avoided when not absolutely necessary).
It's pretty easy to understand what it does (it's an attribute with public 
access, but it's not writable), but you loose meanings (visibility).

read-only is already mentioned here:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented#read-only_and_write-only_properties

But I see now that it is defined as full read only, not even the class itself 
can write to it, so ignore my code examples.

My point was just; we also have the need for public:protected / public:private 
and would like to avoid the overhead of function calls, hence why I looked into 
if there would be ways to sync the two proposals to improve possibility of 
acceptance (ref feedback in thread).




Hence, writing
public $a { get; protected set; }
is more accurate. You recover the lost meaning. But the writing is not 
straightforward.

More, should you write
public read-only $a;
or
public $a { get; private set; }
?

Beside, it seems possible to write
public read-only $a { protected get; private set; }
but that doesn't means anything.


Another examples:
public read-only $a;
vs
public:const $a;

public $a { get; private set; }
vs
public:private $a;

public $a { get; protected set; }
vs
public:protected $a;

We must be able to choose the attribute's visibility.
We should be able to read it without having to read some unnecessary code.
The PHP language should be consistent. I think the visibility information 
shouldn't be distributed on several locations (before the attribute; sometimes 
with a new read-only or write-only keyword; sometimes inside brackets, 
before a new get or set keyword).

Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility

[André Rømcke]

On 7/16/12 5:29 PM, Nikita Popov nikita@gmail.com wrote:


On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard ama...@amaury.net
wrote:
 Yes, but only if you have to write an accessor.
 If you just want an attribute that is:
 - readable from everywhere
 - writable from the current class only

 With my syntax:
 public:private $a;  (read it aloud public reading, private
writing)

 With the existing RFC:
 public $a {
 private set { $this-a = $value; }
 }

 Which one is better? Why should I write code for that?

 If you read the existing RFC, you'll see that all examples involve a
 specific case: when you have a fake attribute, which manipulates date
 stored in other attributes. The given example is an $Hours attributes,
which
 is calculated from the private $Seconds attribute.
 Again, it could be very useful. But it doesn't work all the time.

You can also just write public $a { get; private set; }. I see that
the syntax is a bit more verbose, but I definitely prefer it to the
obscure public:private notation. With the getters/setters the meaning
is somewhat clear (public get, private set), with the colon notation
it isn't really clear.


He probably went with that syntax to retain full flexibility.

In our case (eZ), we almost exclusively use magic getters and setters to
make properties read only. So just like Matthew and others writing api's
we would really appreciate a way to be able to defined read only
properties, without the overhead of function calls.

I think these two proposals can be synced up, what if:

public readonly $a;

Is shorthand for:

public $a { get; protected set; }


And when no function is defined, no function overhead is added.





Nikita

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





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

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

[André Rømcke]

On 7/20/12 2:33 AM, Anthony Ferrara ircmax...@gmail.com wrote:


Hey all,

So I've been thinking about this for a while. Here's what I've come up
with:

1. We want to maintain loose typing, so implementing a different API on
string than on int types would be bad.

2. We want to retain backwards compatibility to some extent with the
legacy
API.

3. We want the ability to simplify the standard library.

So here's my thought. Make $var-method($arg1, $arg2) on scalar types a
short-hand for \php\method($var, $arg1, $arg2).

So we re-organize the base API into \php, cut down to just the base
methods. So:

\php\length()
 - If array, count(), else strlen()
\php\substr()
 - Treat as string always
\php\replace()
 - Normal str_replace semantics
\php\split()
 - Treat as string always
\php\join()
 - Treat as array always
\php\shuffle()
 - If array, array_shuffle, otherwise str_shuffle
\php\pos()
 - if array, array_search(), else strpos()
\php\reverse()
 - if array, array_reverse(), else strrev()
\php\merge()
 - If array, array_merge, if not, string concat
\php\type()
 - return type information about variable
etc

Now, those that are clearly type specific, or are too specialized to
belong
on a global type, would then be sub-namespaced:

\php\array\map()
\php\array\keys()
\php\math\min()
\php\math\max()
\php\math\round()
\php\string\number_format()
\php\string\chr()
\php\string\ord()
etc.

I think I like it, as it is close to how I would proposed it before:
Provide optional PHP6 type classes* and provide an fully oop api on them
in line with other languages. But this is close enough, as it will give
you possibility to explore available methods in IDE if you hint on type.
And you avoid the total chaos you would get if new functions are
introduced in global namespace.
It doesn't automatically gives me strict type hinting possibilities in
api's, but one step at a time.. :P

One nitpic though: method names should be consistently formatted, and most
methods in PHP (5+: DateTime, PDO, XML ...) and user land oop libraries is
often -lowerCamelCase().




* This is where that proposal is usually shoot down, at least it was by
Rasmus and other internals. Argument being the added cost of objects, but
is this the case in other implementations of PHP like HPHP?


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.

Now, there's one more thing that needs to happen. If you call
\php\length($var) directly (procedurally, not as a method call), we'd need
to check if $var is an object that implements -length(), and if so, call
to that instead of an error.

That's the base idea. It could be extended further to include true objects
for scalars, which would implement the rest of the core API. So, you could
do:

(new \php\Array($array))-keys();

This would then assume standard object semantics for the wrapped type,
while at the same time losing the dynamic typing ability of the language
(but it's done on purpose here to keep the API clean).

For BC, we'd need to modify zend_parse_parameters to extract the array
from
a wrapped array object, to keep BC code functioning correctly in either
case, but it should be pretty transparent to the user which is passed...

Is it perfect? Absolutely not. But it tries to get around the BC breaks,
as
well as the dynamic typing issue that ints can be strings, and vise versa.

Thoughts?

Anthony



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

Re: [PHP-DEV] 5.4.0 rc6 and release

[André Rømcke]

On Tue, Mar 27, 2012 at 8:45 AM, Pierre Joye pierre@gmail.com wrote:

 hi,
 hi,

 On Tue, Mar 27, 2012 at 8:38 AM, Clint Byrum cl...@ubuntu.com wrote:

  I think the lesson here is to get the necessary bits from Suhosin into
  PHP's core so that users can feel safe when using stock PHP, rather
  than needing to wait for the good and generous folks at the hardened
  PHP project to catch up.

 I disagree. The lesson here is that the Ubuntu's security team should
 have discussed with us to see what are actually their worries instead
 of not following what is actually a good move for everyone.



Why? It is common practice to avoid .0 releases, including those from PHP :)

Actually, this is not a bad thing at all.
It makes sure lots of PHP projects and Frameworks stays on 5.3 as a common
base for the next 1-3 years, introp wise that is a good thing.

And those that want the extra 5.4 stuff can get it somehow anyway, and as
part of the distro in 7 months.



 Cheers,
 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Re: [PHP-DEV] 5.4.0 rc6 and release

[André Rømcke]

On Fri, Jan 20, 2012 at 1:43 AM, Clint Byrum cl...@ubuntu.com wrote:

 Excerpts from Stas Malyshev's message of Thu Jan 19 16:08:28 -0800 2012:
  Hi!
 
   - According to this website there are still 94 test failures in 5.4 .
   Can you confirm all of them are minor problems?
   http://gcov.php.net/viewer.php?version=PHP_5_4
 
  Most of them appear so, I'll go through them again to be sure and
  encourage others to do so too and raise red flags if somebody sees
  something bad there.
  Unfortunately, some tests are environment-dependent or otherwise have
  subtle dependencies or structure that make them work on one system and
  fail on another not because of the bug in PHP but because of the test
  itself. So, I have 0 fails on my Linux build but 6 fails on my Mac
  build. Other times some systems may not support some capability, use old
  version of the library, etc. and the test may not account for that.

 These tests should be skipped or marked as XFAIL on platforms they are
 known to fail on. Better to have no test than one that cannot be relied
 upon. All supported platforms should pass with 0 fails. These intentional
 skips should have open bugs that are documented in the test code so that
 a developer can find out why this test was disabled when trying to make
 a change covered by the test.

 
  I do not think it is practical to postpone release until we solve all of
  such problems, since this being volunteer-driven open-source project
  this means not having any release schedule at all. I prefer having the
  schedule even if that means we'd have to release with some known
  deficiencies.
 

 Its pretty bad actually. For all of PHP's success, this is something that
 continues to baffle me, and many others I have talked to who are charged
 with measuring quality and with patching systems in a timely manner. How
 better to document unreliable tests than to skip them with something like
 SKIPPED - known to fail on Mac.

 Its precisely this unreliability that forced me to take a conservative
 approach for Ubuntu 12.04 and recommend to the community that we ship
 5.3.9 instead of 5.4.0. I would much rather have the new stuff in, but
 even if all the tests pass on the machine we run the test suite on,
 how can we be sure they won't fail in another time zone, or in some
 other strange configuration?



Given that 12.04 beta2 will be out on Thursday, and the unit tests where
fixed before shipping 5.4 (I naively assume), is this in or out?
ref: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54

With beta freeze on march 22 I guess the mistake of bundeling 5.3 instead
of 5.4 is already made, and we will have to live with that for the next 2
years for prod, and the next 7 months for dev.






   - There was this problem with 5.3.7 and the crypt() bug. Has there been
   some improvement in the process of handling test failures? For example
   mark expected failures as expected failures, and fix the tests or the
   code? Or are the failing tests stable since month and all of them are
   minor problems?
 
  Yes, there was work done on these. Most of those were fixed, but few
  still remain, especially across various environments (i.e. test may be
  fine on some but not others). I of course am all for fixing that further
  and welcome any help on that.
 
   - There have been 319 unique failed tests in RC5, reported by user
   tests. Is someone looking into them and trying to classify and/or fix
 them?
   http://qa.php.net/reports/
 
  Non-reproducible failures usually mean the problem is with the test
  itself, or with the difference of expectations in the test and local
  environment, not with PHP. It may still be PHP problem, of course, so
  the person running the test should check it out and submit a bug if
  appropriate and if it's bad enough, also send a message to this list.
 
   All in all the number of test failures still feels very high, I would
 be
   interested in your opinion. Is this normal for big projects like
 this?
 
  I do think it should be reduced, however if the choice is between
  waiting forever and have release with some bugs, I think it is practical
  to choose the latter. Of course, if we discover a major problem that
  makes PHP unusable or seriously impacts many PHP users, it will be dealt
  with immediately, and had been so in the past, but otherwise we have to
  work within the realities of a big project with limited resources and
  realize that while we strive for 0 bugs in every release, it may never
  be possible.

 All software will have bugs. The test suite, however, should reflect
 the bits of code that you know work reliably... not the bits of code
 you know work most of the time.

 The fact that its all being running regularly is a fantastic improvement.
 I'd like to see a commitment to getting 100% pass/xfail/skip for every
 release/tested environment in future releases though.

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, 

Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4

[André Rømcke]

On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs tyr...@gmail.com wrote:



 On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT 
 patrickalla...@php.netwrote:

 2011/12/27 Ilia Alshanetsky i...@ilia.ws:
  The change is inside 5.4 version which adjust breaks BC.

 I don't follow you here Ilia.

 As per https://wiki.php.net/rfc/releaseprocess:
 * Backward compatibility must be respected with the same major
 releases, for example from 5.2 to 5.6.
 * Going from x.y.z to x.y+1.z, it is ok to break *binary*
 compatibility but Backward compatibility must be kept.

 However:

 new DateTime(@{$_SERVER['REQUEST_TIME']});

 works in 5.3 but not in 5.4.
 AFAIK, creating a DateTime object based on the REQUEST_TIME is not an
 exotic thing.
 For sure, the fix is easy, but that is not the point, it *will*
 actually break applications.

 Did I miss something?


 I think that he is referring to that we already break BC with 5.4
 (removing magic_quotes, register_globals, break/continue
 $var, allow_call_time_pass_reference, some deprecated session_ functions,
 safe_mode, etc. for a complete list see
 http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/UPGRADING?view=markup
  )



These are mostly removal of features, and most of these have been
deprecated for quite a while.
The REQUEST_TIME change however is a change of behaviour that has not been
warned about up front, which imo is a worse BC break then most of the rest.
And arguing for ignoring one bc break/bug/mistake because there are others
is.. well.. :)




 However I tend to agree with you, that this BC break isn't really worth
 it, we can see that there are common apps stumbling across this change, and
 albeit the new behavior can be useful for many people, they wouldn't really
 mind if we add this as a new variable imo.



Great, so I do think most people agree that this can, and should be fixed
before 5.4 by instead expose microtime on a separate variable called
REQUEST_TIME_FLOAT.

+1

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[André Rømcke]

On Sat, Dec 24, 2011 at 8:40 AM, Will Fitch will.fi...@gmail.com wrote:

 In the interest of providing options for an ability to mark a method as
 returning null, I have added a new patch here:
 http://www.willfitch.com/php/nullable.patch

 This includes a new token T_NULLABLE.  Here are a few examples:

 // This is allowed
 private nullable ArrayIterator getIterator()
 {
return null;
 }

 // This throws an E_RECOVERABLE_ERROR
 private ArrayIterator getIterator()
 {
 return null;
 }

 The token/identifier can certainly change, but I want to provide the most
 options for the best solution.



This looks fine to me, looks more php like then the C# examples.





 On Dec 23, 2011, at 6:31 PM, André Rømcke wrote:

 2011/12/23 John Crenshaw johncrens...@priacta.com

  From: Will Fitch [mailto:will.fi...@gmail.com]
 
  I would like to take this opportunity to query on a consensus:
 
  Would you prefer to allow methods with type hinted return values to
 return null at will, or add a marker noting that it *may* return null?
 
  Example: Return null at will
 
  public ArrayIterator getIterator()
  {
 // something happened, will return null
 return null;
  }
 
  Example: Return only if identified as such
 
  public ArrayIterator? getIterator()
  {
  return null;
  }

 I hate the syntax in the second example (using ?).



 It looks strange, but easy to get used to. Two examples from C#:

 public decimal? Grade { get; set; }

 public NullableSystem.DateTime Time { get; set; }





 IMO allowing null should be the default unless specifically disallowed.


 I disagree for the reasons mentioned by for instance Robert.
 Type hints should be strict/explicit or not done at all.



For the record; This was not ment as an argument against scalar, and
similar type hints ( object, callable.. ) .
It was an argument against hinting about something and getting
something completely different (null).



Happy xmas!

[PHP-DEV] REQUEST_TIME change in PHP 5.4

[André Rømcke]

Hi,



a bit late to the party maybe, but why was REQUEST_TIME broken in 5.4
instead of adding a new parameter? (like REQUEST_MICROTIME)
Is the Release Process not followed yet?


   - x.y.z to x.y+1.z
  - (...)
  - Backward compatibility must be kept

( https://wiki.php.net/rfc/releaseprocess )


It is not a big deal (we are used to it), but it does break a couple of
things in for instance eZ Publish  Zeta Components which will by the
nature of things not be fixed before the next release.
Most customers will hopefully make sure the version of the software they
are using is tested/certified for php 5.4 before upgrading, but from
experience, some will not.


Other then that, happy xmas!

Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4

[André Rømcke]

On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans der...@php.net wrote:

 On Sat, 24 Dec 2011, Pierre Joye wrote:

  hm, I should read better...
 
  The REQUEST_TIME value inside server now returns a floating point
 number
 
  How does it break BC except if one is doing a strong type test? which
  makes very little sense in this case.
 
  While a fix is easy, (int) casting and works with all previous
  versions, I would like to know how it breaks apps out there.

 new DateTime(@{$_SERVER['REQUEST_TIME']}); f.e.



Yes, this is the one from Zeta Components MvcTools.
In eZ Publish it was db based session gc using REQUEST_TIME
and compatibility for potential extensions that might have used this
variable via eZ Publish api:
https://github.com/ezsystems/ezpublish/commit/3483c623769aa9ed3be7b6f33e3579cf8a8efd45

In both cases a (int) was added in front of the variable to make sure it
still behaves the same, so not a big deal.
But as also mentioned, changes like this requires patching to
be compatible with 5.4.

So unless this is done to be inline with some standard on such a server
variable, I would suggest placing microtime on a separate server variable
(since it is indeed useful to have it for time accumulators and performance
metrics).

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[André Rømcke]

2011/12/23 John Crenshaw johncrens...@priacta.com

  From: Will Fitch [mailto:will.fi...@gmail.com]
 
  I would like to take this opportunity to query on a consensus:
 
  Would you prefer to allow methods with type hinted return values to
 return null at will, or add a marker noting that it *may* return null?
 
  Example: Return null at will
 
  public ArrayIterator getIterator()
  {
 // something happened, will return null
 return null;
  }
 
  Example: Return only if identified as such
 
  public ArrayIterator? getIterator()
  {
  return null;
  }

 I hate the syntax in the second example (using ?).



It looks strange, but easy to get used to. Two examples from C#:

public decimal? Grade { get; set; }

public NullableSystem.DateTime Time { get; set; }





 IMO allowing null should be the default unless specifically disallowed.


I disagree for the reasons mentioned by for instance Robert.
Type hints should be strict/explicit or not done at all.

Re: [PHP-DEV] SplClassLoader RFC Voting phase

[André Rømcke]

On Tue, Nov 8, 2011 at 6:55 PM, guilhermebla...@gmail.com 
guilhermebla...@gmail.com wrote:

 Hi Nikita,

 Thanks.
 It's your option and I won't fight. But it seems my proposal is not yet
 100%.
 Some things I have either identified or people have reported.

 1- Remove -register() and -unregister(), and make the
 spl_autoload_register to support SplClassLoader.

 I'm really +0 on this one.
 But since the proposal covers an OO approach for autoload, it makes
 sense the registering is pat of the available API, not in procedural
 land.



+1 on remove, don't duplicate things already part of php.


While on duplication, why complicate things by having custom
$includePathLookup support?
This is already handled by php isn't it?



 2- Remove constructor prototype in interface

 After some thought it makes sense, but only if interface then defines
 the setMode prototype.
 The background for this is supported if the user decides to enhance
 the base class to support caching, requiring the injection of the
 Cache layer in constructor. If it's part of the interface, it cannot
 be changed.
 I took this example after looking at Symfony's
 ApcUniversalClassLoader:

 https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.php



+1 on removing constructor from interface.
But imo SplClassLoader should have a constructor where you can optionally
provide a hash of namespace and path, so you can do:

spl_autoload_register( new SplClassLoader( array(
'ns' = 'path/',
'ns2' = 'path2/'
) ) );

(assuming spl_autoload_register gets native support for SplAutoloader,
otherwise it it will of course have to be provided as a callback)

Re: [PHP-DEV] SplClassLoader

[André Rømcke]

 a sense of
  justification of this standard and a base in which to push forward.
  It's also giving existing lib vendors to easily switch to a well-built
  autoloading mechanism bundled with PHP rather than relying on
  third-party code to provide that. Additionally the small performance
  boost but including SplClassLoader is not driven by the speed benefit
  but by the community/library benefit.
 
  This appears to be the general consensus of PSR-0 and my opinion on the
 matter.
 
  Regards,
  Paul Dragoonis.
 
 
 
  On Thu, Nov 3, 2011 at 10:56 AM, André Rømcke a...@ez.no wrote:
  On Thu, Oct 27, 2011 at 4:30 AM, Laruence larue...@php.net wrote:
 
  2011/10/26 André Rømcke a...@ez.no:
   On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com 
   guilhermebla...@gmail.com wrote:
  
   Hi internals,
  
   For all those interested, I have updated the RFC with better
   explanation, included example implementation and also example
 usage.
   If you have any other wishes, doubts, etc, feel free to ask on this
   thread and I'll quickly answer here and also update the RFC
   accordingly.
  
  
  
   As sent to the PHP-SWG list, a small change / addition to PSR-0
 would
   simplify the matching considerably.
  
   If this rule:
   * Each “_” character in the CLASS NAME is converted to a
   DIRECTORY_SEPARATOR. The “_” character has no special meaning in the
   namespace.
  
   is changed to
   * Each “_” character in the CLASS NAME and NAMESPACE is converted
 to a
   DIRECTORY_SEPARATOR.
  There is a internal autoloader in
  Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup
 ),
  in it the T_NS_SEPARATOR will convert to be _, then convert to be
  DIRECTORY_SEPARATOR.
 
  thanks
 
 
 
  As mentioned by others this will have to go into a new PSR standard as
  PSR-0 was accepted 2 years ago.
 
  And assuming that a C implementation will greatly out-weight the
 reduced
  amount of str functions in terms performance we should not block this
  process to get it into 5.4 by taking up off-topic subjects like
 mentioning
  things not part of PSR-0.
 
  But!
 
  The implementation proposal (rfc) should be adjusted to be
  forward compatible, including support for several namespaces pr
 instance
  (mention by several on PSR mailing list) imho.
 
  Possible example (additional arguments can be added later when more
  features are added, aka a PSR-1 mode):
 
  new SplClassLoader( array( 'Doctrine\Common' = '/path/to/doctrine' )
 );
 
 
  Or something like this (if we want the options to be an array):
 
  new SplClassLoader( array( 'ns' = array( 'Doctrine\Common' =
  '/path/to/doctrine' ) ) );
 
 
  For documentation and argument validation, imo the former approach
 would be
  better.
  So what is the status here? thread has been silent for a while.
 
 
  
   Or a strict mode is added to enable that, then you'll reduce 6
 string
   function to 2, and still have backward support for PEAR class
 naming(w/o
   namespace).
  
  
  
  
   The url for the RFC is: https://wiki.php.net/rfc/splclassloader
  
   Cheers,
  
   On Mon, Oct 24, 2011 at 7:55 PM, David Coallier dav...@php.net
 wrote:
   
Could you open a FR at bugs.php.net and attach the patch to it
  please?
Could be easier to track  (and the # to the RFC too :)
   
   
Yeah I'll do that once I have the tests adjusted and once I know
 the
patch actually works as expected.
   
--
David Coallier
   
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
   
   
  
  
  
   --
   Guilherme Blanco
   Mobile: +55 (11) 8118-4422
   MSN: guilhermebla...@hotmail.com
   São Paulo - SP/Brazil
  
   --
   PHP Internals - PHP Runtime Development Mailing List
   To unsubscribe, visit: http://www.php.net/unsub.php
  
  
  
 
 
 
  --
  Laruence  Xinchen Hui
  http://www.laruence.com/
 
 
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 

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

Re: [PHP-DEV] SplClassLoader

[André Rømcke]

On Thu, Oct 27, 2011 at 4:30 AM, Laruence larue...@php.net wrote:

 2011/10/26 André Rømcke a...@ez.no:
  On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com 
  guilhermebla...@gmail.com wrote:
 
  Hi internals,
 
  For all those interested, I have updated the RFC with better
  explanation, included example implementation and also example usage.
  If you have any other wishes, doubts, etc, feel free to ask on this
  thread and I'll quickly answer here and also update the RFC
  accordingly.
 
 
 
  As sent to the PHP-SWG list, a small change / addition to PSR-0 would
  simplify the matching considerably.
 
  If this rule:
  * Each “_” character in the CLASS NAME is converted to a
  DIRECTORY_SEPARATOR. The “_” character has no special meaning in the
  namespace.
 
  is changed to
  * Each “_” character in the CLASS NAME and NAMESPACE is converted to a
  DIRECTORY_SEPARATOR.
 There is a internal autoloader in
 Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup),
 in it the T_NS_SEPARATOR will convert to be _, then convert to be
 DIRECTORY_SEPARATOR.

 thanks



As mentioned by others this will have to go into a new PSR standard as
PSR-0 was accepted 2 years ago.

And assuming that a C implementation will greatly out-weight the reduced
amount of str functions in terms performance we should not block this
process to get it into 5.4 by taking up off-topic subjects like mentioning
things not part of PSR-0.

But!

The implementation proposal (rfc) should be adjusted to be
forward compatible, including support for several namespaces pr instance
(mention by several on PSR mailing list) imho.

Possible example (additional arguments can be added later when more
features are added, aka a PSR-1 mode):

new SplClassLoader( array( 'Doctrine\Common' = '/path/to/doctrine' ) );


Or something like this (if we want the options to be an array):

new SplClassLoader( array( 'ns' = array( 'Doctrine\Common' =
'/path/to/doctrine' ) ) );


For documentation and argument validation, imo the former approach would be
better.
So what is the status here? thread has been silent for a while.


 
  Or a strict mode is added to enable that, then you'll reduce 6 string
  function to 2, and still have backward support for PEAR class naming(w/o
  namespace).
 
 
 
 
  The url for the RFC is: https://wiki.php.net/rfc/splclassloader
 
  Cheers,
 
  On Mon, Oct 24, 2011 at 7:55 PM, David Coallier dav...@php.net wrote:
  
   Could you open a FR at bugs.php.net and attach the patch to it
 please?
   Could be easier to track  (and the # to the RFC too :)
  
  
   Yeah I'll do that once I have the tests adjusted and once I know the
   patch actually works as expected.
  
   --
   David Coallier
  
   --
   PHP Internals - PHP Runtime Development Mailing List
   To unsubscribe, visit: http://www.php.net/unsub.php
  
  
 
 
 
  --
  Guilherme Blanco
  Mobile: +55 (11) 8118-4422
  MSN: guilhermebla...@hotmail.com
  São Paulo - SP/Brazil
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 



 --
 Laruence  Xinchen Hui
 http://www.laruence.com/

Re: [PHP-DEV] SplClassLoader

[André Rømcke]

On Thu, Nov 3, 2011 at 4:19 PM, Anthony Ferrara ircmax...@gmail.com wrote:

 Can I make a point here.

 Why the heck are we caring about the performance of the autoloader at
 all here?  The filesystem operations necessary (at least the stat()
 call) will greatly dominate any string function.  And considering that
 even the biggest framework only has perhaps a few hundred classes,
 you're talking about incredibly small performance gains here.  Even if
 you save a microsecond in string operations (try it, even in PHP the
 string operations can be done in around 10 or 20 microseconds), after
 all classes are loaded you're only talking about a 1 or 2 milliseconds
 of gain in the application.

 I'm not saying that we shouldn't try to save time where we can, but
 given the controversial nature of this addition, I don't think that a
 micro-optimization (which is what this really is) should be used as a
 justification for why it should be included.  It's not like we're
 talking about implementing a computationally difficult task into C
 (such as a cryptographic algorithm) where putting it into C would
 create a huge performance gain.  We're talking about implementing a
 function which already is dominated by non-computational overhead into
 C to save a few milliseconds.  The number of instances that will
 benefit from such an addition are incredibly small.  Saving 2
 milliseconds on an application (that likely takes hundreds of
 milliseconds to render) would require a huge number of requests to
 amortize into an actual measurable benefit.  And those that do benefit
 would have access to their server farm to add the pecl extension
 anyway.  So there's really no practical performance gain to the
 community as a whole, hence confirming that this is a
 micro-optimization.

 Personally I feel that this does not belong in the core (especially
 not yet as with the inconsistencies).

 But that's besides the point.  I just want to emphasize the point that
 performance should not be a criteria for justifying it going into the
 core...



You mixing up one of my personal objectives* with the poster's objective**
(which I also share).


* making the class map based vs convention based performance discussion
moot, making sure more people will standardize around PSR-0
** making sure there is a autoloader in php that follows a convention that
people actually use, and further standardized how such a basic thing is
done in php projects in the wild.







 On Thu, Nov 3, 2011 at 10:56 AM, André Rømcke a...@ez.no wrote:
  On Thu, Oct 27, 2011 at 4:30 AM, Laruence larue...@php.net wrote:
 
  2011/10/26 André Rømcke a...@ez.no:
   On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com 
   guilhermebla...@gmail.com wrote:
  
   Hi internals,
  
   For all those interested, I have updated the RFC with better
   explanation, included example implementation and also example usage.
   If you have any other wishes, doubts, etc, feel free to ask on this
   thread and I'll quickly answer here and also update the RFC
   accordingly.
  
  
  
   As sent to the PHP-SWG list, a small change / addition to PSR-0 would
   simplify the matching considerably.
  
   If this rule:
   * Each “_” character in the CLASS NAME is converted to a
   DIRECTORY_SEPARATOR. The “_” character has no special meaning in the
   namespace.
  
   is changed to
   * Each “_” character in the CLASS NAME and NAMESPACE is converted to a
   DIRECTORY_SEPARATOR.
  There is a internal autoloader in
  Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup),
  in it the T_NS_SEPARATOR will convert to be _, then convert to be
  DIRECTORY_SEPARATOR.
 
  thanks
 
 
 
  As mentioned by others this will have to go into a new PSR standard as
  PSR-0 was accepted 2 years ago.
 
  And assuming that a C implementation will greatly out-weight the reduced
  amount of str functions in terms performance we should not block this
  process to get it into 5.4 by taking up off-topic subjects like
 mentioning
  things not part of PSR-0.
 
  But!
 
  The implementation proposal (rfc) should be adjusted to be
  forward compatible, including support for several namespaces pr instance
  (mention by several on PSR mailing list) imho.
 
  Possible example (additional arguments can be added later when more
  features are added, aka a PSR-1 mode):
 
  new SplClassLoader( array( 'Doctrine\Common' = '/path/to/doctrine' ) );
 
 
  Or something like this (if we want the options to be an array):
 
  new SplClassLoader( array( 'ns' = array( 'Doctrine\Common' =
  '/path/to/doctrine' ) ) );
 
 
  For documentation and argument validation, imo the former approach would
 be
  better.
  So what is the status here? thread has been silent for a while.
 
 
  
   Or a strict mode is added to enable that, then you'll reduce 6 string
   function to 2, and still have backward support for PEAR class
 naming(w/o
   namespace).
  
  
  
  
   The url for the RFC is: https://wiki.php.net/rfc

Re: [PHP-DEV] SplClassLoader

[André Rømcke]

On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com 
guilhermebla...@gmail.com wrote:

 Hi internals,

 For all those interested, I have updated the RFC with better
 explanation, included example implementation and also example usage.
 If you have any other wishes, doubts, etc, feel free to ask on this
 thread and I'll quickly answer here and also update the RFC
 accordingly.



As sent to the PHP-SWG list, a small change / addition to PSR-0 would
simplify the matching considerably.

If this rule:
* Each “_” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “_” character has no special meaning in the
namespace.

is changed to
* Each “_” character in the CLASS NAME and NAMESPACE is converted to a
DIRECTORY_SEPARATOR.

Or a strict mode is added to enable that, then you'll reduce 6 string
function to 2, and still have backward support for PEAR class naming(w/o
namespace).




 The url for the RFC is: https://wiki.php.net/rfc/splclassloader

 Cheers,

 On Mon, Oct 24, 2011 at 7:55 PM, David Coallier dav...@php.net wrote:
 
  Could you open a FR at bugs.php.net and attach the patch to it please?
  Could be easier to track  (and the # to the RFC too :)
 
 
  Yeah I'll do that once I have the tests adjusted and once I know the
  patch actually works as expected.
 
  --
  David Coallier
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 



 --
 Guilherme Blanco
 Mobile: +55 (11) 8118-4422
 MSN: guilhermebla...@hotmail.com
 São Paulo - SP/Brazil

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

Re: [PHP-DEV] SplClassLoader

[André Rømcke]

On Tue, Oct 25, 2011 at 12:49 PM, Benjamin Eberlei kont...@beberlei.dewrote:

 I think the following two requirements should be covered by configuration
 aswell:

 1. Have the autoloader be silent, i.e. doing a file_exists() check. API
 idea
 $loader = new SplClassLoader(..., SplClassLoader::SILENT);
 2. Have a ASSERT_CLASS_EXISTS mode, i.e. after the require an
 if(!class_exists($class)) = throw new LogicException(SplClassLoader
 expects class $class to be in $file, but after requiring the file this
 class
 is still not loaded.); API here aswell new SplCloassLoader(...,
 SplClassLoader::ASSERT_CLASS_EXISTS)



What if 5.4 enhanced class_exists() to send a second true argument (an
optional argument, where default should be false) to autoloaders, then users
wouldn't have to deal with silent vs noisy modes at all.

So signature of autoload functions becomes:
function load( string $className, bool $checkExistence = false );

In the case of splClassLoader, $checkExistence = false would for instance
mean you would get a *E_COMPILE_ERROR *(requrie) if the class does not exist
but does match the configured root name spaced to be handled, if the
argument is true, then a bool is returned.





 greetings,
 Benjamin

 On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com 
 guilhermebla...@gmail.com wrote:

  Hi internals,
 
  For all those interested, I have updated the RFC with better
  explanation, included example implementation and also example usage.
  If you have any other wishes, doubts, etc, feel free to ask on this
  thread and I'll quickly answer here and also update the RFC
  accordingly.
 
  The url for the RFC is: https://wiki.php.net/rfc/splclassloader
 
  Cheers,
 
  On Mon, Oct 24, 2011 at 7:55 PM, David Coallier dav...@php.net wrote:
  
   Could you open a FR at bugs.php.net and attach the patch to it
 please?
   Could be easier to track  (and the # to the RFC too :)
  
  
   Yeah I'll do that once I have the tests adjusted and once I know the
   patch actually works as expected.
  
   --
   David Coallier
  
   --
   PHP Internals - PHP Runtime Development Mailing List
   To unsubscribe, visit: http://www.php.net/unsub.php
  
  
 
 
 
  --
  Guilherme Blanco
  Mobile: +55 (11) 8118-4422
  MSN: guilhermebla...@hotmail.com
  São Paulo - SP/Brazil
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 

[PHP-DEV] Anonymous functions are currently implemented using the Closure class. This is an implementation detail and should not be relied upon.

[André Rømcke]

Despite several mentions in the manual, lots of php 5.3 code uses this with
instanceof or in function signature (eg: Doctrine 2).

If you don't want to support this in the future, could this be cleaned-up in
5.4?
( the longer you wait, the more you break )

Possibly by creating a interface called Closure, and change the name of the
actual class + implement the Closure interface..



Best Regards / Med vennlig hilsen
André R.

Re: [PHP-DEV] Property get/set syntax

[André Rømcke]

On Wed, Aug 10, 2011 at 10:16 PM, Kalle Sommer Nielsen ka...@php.netwrote:

 Hi Sebastian

 2011/8/10 Sebastian Krebs sebastian.krebs.ber...@googlemail.com:
  Hi,
 
  From time to time I'm looking over the existing RFCs and I'm wondering
 what
  happens to them. For example Property get/set syntax [1]. As far as I
 can
  see its already accepted for PHP6 [2], but now it seems to be orphaned.
 In
  my opinion it is a very nice enhancement, that helps to get rid of the
  Getter/Setter-mess. Are there any plans?

 This RFC by Dennis was never 100% finalized, however from what I
 remember it was suggested too late in 5.3's development process to be
 implemented, and so do I think we are in 5.4 already as the RFC would
 need some extra care before sent to the list, perhaps even a patch for
 parts of it.


Type hinting is for instance not covered (should imho at least be on pair
with function signatures).



 The RFC itself evolved quite a bit doing its drafts on the wiki, I
 remember having long emails with Dennis about the syntax, as it
 evolved to allow many more things and additions to the object model,
 like final properties, interfaces with properties, getters, setters,
  But in the end I think it would rime greatly with traits and
 other goodies in 5.4 if someone took the time and care for this RFC,
 just worried its way too late already.



On 6.0 todo list:
There are lots of things that would be nice additions to php on the 6.0 todo
list*.
If all these have been voted for in the past, I'll suggest that they could
be worked on in upcoming 5.x versions as well leading up to an eventual 6.0
version.

*eg:

   - Property overloading RFC aka abstract/virtual properties and get/set
   handlers (derick) (related?)
   - add support for type-hinted return values. *caugh*
   - add ability to allocate persistent zvals in PHP.
   - add support for files 2GB once native 64bit integers are implemented
   (pierre,wez)
   - APC
  - include APC in the core distributions (turned off by default) and
  switch to mmap as default shared memory storage.
  - ability to move autoloaded main classes in apc's class lookup
  preventing the overhead of doing the inheritance process all the time.
  (marcus)





 --
 regards,

 Kalle Sommer Nielsen
 ka...@php.net

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

Re: [PHP-DEV] Extensions to traits

[André Rømcke]

On Thu, Feb 10, 2011 at 6:25 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.auwrote:

 On 11/02/11 3:37 AM, Philip Olson wrote:

 You now have rights to the wiki rfc namespace.


 Thanks a lot, Philip.

 I have now made an RFC based on the most recent discussions:

 http://wiki.php.net/rfc/traitsmodifications

 I think this is a more solid proposal than my original one, and I hope
 we can continue to discuss it and agree to the extent that it's worth
 starting an implementation.

 Please read it and comment whenever you can find some time, guys!



As for your first example:


trait T {
   public function foo() {
  echo http://www.php.net/echo T;
   }}class C {
   use T;
   public function foo() {
  echo http://www.php.net/echo C;
   }}


I think it would sometimes be desirable to allow this, for instance when a
trait has been updated in a framework to adapt to what has become common
practice in classes that uses it in the wild.
( I assume you already get error if function signature is different like in
inheritance? )

So to allow both cases, what about letting people use the final keyword on
functions to signal functions that can not be re declared without alias. Or
better, add a new keyword since final should mean final.

My 2 Euro cents,

André

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

[André Rømcke]

On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.netwrote:

 2010/11/30 Kalle Sommer Nielsen ka...@php.net:
  Hi
 
  2010/11/30 Patrick ALLAERT patrickalla...@php.net:
  With this patch, something looks inconsistent to me:
  Both properties and methods have a visibility
  (public|protected|private) and a keyword: var (T_VAR) and function
  (T_FUNCTION) respectively.
  However private var $foo; generates a fatal error but private
  function foo(){} not?
 
  The var keyword is an alias of the public keyword for BC with
  PHP4. So it would be illogically to declare a property both private
  and public at the same time ;-)

 Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
 introducing the possible omission of T_FUNCTION?


Why?

This will break lots of code, does it improve anything while at it? Is 'var'
hindering anything? Is it taking up a lot of code?
If it is removed then that should be in trunk aka 6.0 the 2nd , and not in
5.x.

Re: [PHP-DEV] Hold off 5.4

[André Rømcke]

On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans der...@php.net wrote:

 On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:

  On 2010-11-23, Derick Rethans der...@php.net wrote:
   On Mon, 22 Nov 2010, Felipe Pena wrote:
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}
  
   Yeah, there is a slight hint of a BC break in case you have a class
   named int or float etc. But there is:
   http://uk.php.net/manual/en/userlandnaming.tips.php
  
   Perhaps we can reduce the current list of classes:
   int, integer, real, double, string, binary, scalar, array, object,
   bool, boolean
   to what the manual uses though (for prototypes):
   int, float, string, binary, scalar, array, object, bool
   (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
 
  Sorry, but this is actually a pretty grave BC break.
 
  Currently, you can do the following:
 
  namespace Foo\Validator;
 
  class Int {}

 During our namespace discussion, this is exactly what I warned about. In
 order to make use of namespaces, you need to have atleast two elements
 in your class names otherwise we can still never introduce a new class.
 But that was not listened too.

  As Sebastian noted, it seems this should be addressed with the new
  lexer; I'd argue that if the current type hinting must introduce new
  keywords, it should wait until the new lexer is in place in order to
  insulate end-users from such changes.

 The new lexer however, is a slower; so not a viable solution right now.

  With a defined release process, *everyone* knows what must be done, by
  when, making the process more transparent and *gasp* democratic.

 Well, I don't think we've ever been democratic. I probably think
 that that wouldn't even work. Also, I think an alpha has pretty much
 been announce nicely on time for people to know what's happening.



I think what Matthew suggest here is something in the line of democratically
defining a release process up front: features you would like to get in (a
roadmap that clearly states that the content can change up until a feature
freeze), a deadline for the feature freeze so that the process is
predictable and appoint a release manager to be in charge of the branch.

Something like:
- Branching next version from day one so you have one called next and one
called trunk for edge stuff, and appoint a release manager to approve
features as they are merged from development branch(es)
 Alternatively (among several possible branch strategies) in DVCS you could
use topic branches for the edge implementations, this is cleaner (maybe),
but the point is to have a release branch that can be stabilized at anytime.
 For a more in-depth branching possibility see:
http://nvie.com/posts/a-successful-git-branching-model/

- Define a feature freeze date, anything not ready feature or stability wise
is moved to Next Next roadmap (they are not in the Next release branch
anyway as it only has feature complete features at any point)
And branch off Next Next and appoint a release manager for that branch so
there is always an active release branch.

This will give a more predictable release schedule for everyone involved,
especially for php users as it will give them a real hint on when the
testing process of the next version will begin and some clue on when it
might get finalized. All without having to introduce full fledge scrum and /
or a strict release process.


- ar

Re: [PHP-DEV] Hold off 5.4

[André Rømcke]

On Wed, Nov 24, 2010 at 1:41 PM, André Rømcke a...@ez.no wrote:

 On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans der...@php.net wrote:

 On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:

  On 2010-11-23, Derick Rethans der...@php.net wrote:
   On Mon, 22 Nov 2010, Felipe Pena wrote:
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}
  
   Yeah, there is a slight hint of a BC break in case you have a class
   named int or float etc. But there is:
   http://uk.php.net/manual/en/userlandnaming.tips.php
  
   Perhaps we can reduce the current list of classes:
   int, integer, real, double, string, binary, scalar, array, object,
   bool, boolean
   to what the manual uses though (for prototypes):
   int, float, string, binary, scalar, array, object, bool
   (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php
 )
 
  Sorry, but this is actually a pretty grave BC break.
 
  Currently, you can do the following:
 
  namespace Foo\Validator;
 
  class Int {}

 During our namespace discussion, this is exactly what I warned about. In
 order to make use of namespaces, you need to have atleast two elements
 in your class names otherwise we can still never introduce a new class.
 But that was not listened too.

  As Sebastian noted, it seems this should be addressed with the new
  lexer; I'd argue that if the current type hinting must introduce new
  keywords, it should wait until the new lexer is in place in order to
  insulate end-users from such changes.

 The new lexer however, is a slower; so not a viable solution right now.

  With a defined release process, *everyone* knows what must be done, by
  when, making the process more transparent and *gasp* democratic.

 Well, I don't think we've ever been democratic. I probably think
 that that wouldn't even work. Also, I think an alpha has pretty much
 been announce nicely on time for people to know what's happening.



 I think what Matthew suggest here is something in the line of
 democratically defining a release process up front: features you would like
 to get in (a roadmap that clearly states that the content can change up
 until a feature freeze), a deadline for the feature freeze so that the
 process is predictable and appoint a release manager to be in charge of the
 branch.

 Something like:
 - Branching next version from day one so you have one called next and one
 called trunk for edge stuff, and appoint a release manager to approve
 features as they are merged from development branch(es)
  Alternatively (among several possible branch strategies) in DVCS you could
 use topic branches for the edge implementations, this is cleaner (maybe),
 but the point is to have a release branch that can be stabilized at anytime.
  For a more in-depth branching possibility see:
 http://nvie.com/posts/a-successful-git-branching-model/

 - Define a feature freeze date, anything not ready feature or stability
 wise is moved to Next Next roadmap (they are not in the Next release branch
 anyway as it only has feature complete features at any point)
 And branch off Next Next and appoint a release manager for that branch so
 there is always an active release branch.


When feature freeze date for Next is reached.



 This will give a more predictable release schedule for everyone involved,
 especially for php users as it will give them a real hint on when the
 testing process of the next version will begin and some clue on when it
 might get finalized. All without having to introduce full fledge scrum and /
 or a strict release process.


 - ar

Re: [PHP-DEV] PHP 5.4: Adding APC

[André Rømcke]

On Tue, Nov 2, 2010 at 9:57 AM, Lester Caine les...@lsces.co.uk wrote:

 Derick Rethans wrote:

 Actually, Kalle just pointed out that it compiles just fine. In that
 case, I think we should put it in trunk and in the 5.4 alpha.


 As long as it is disabled by default and can easily be replaced by
 preferred alternatives ... eaccelerator is still working fine now that it
 has been upgraded to handle 5.3 ... although it would be nice to see some
 more up to date comparisons. Although I suspect in reality, the combination
 with database and other caching activity means that a straight comparison
 may be a little meaningless? Change the database and the figures are going
 to be different anyway ... so a straight comparison on non-database code
 would be a little more practical.


+1. Being disabled by default was agreed on for old 6.x so should be for
5.4 as well.

However I think there probably is a lot of possibilities for PHP if it was
better integrated in the future (lets say new 6.x).
To offer better autoload performance if you stick to PSR-0 for class
autoloading for instance. Hence a future php version that has better
persistent knowledge of classes used on the system so every class load
doesn't result in a full require call with all its overhead on every
request.
And/Or a shared api / backend for shared persistent cache for stat calls,
real path and parsed php structures, and anything else one might want to let
persist between requests in the future.
A discussion for another thread some other time off course.




 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk//
 Firebird - http://www.firebirdsql.org/index.php


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

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[André Rømcke]

On Mon, Nov 1, 2010 at 9:47 PM, Felipe Pena felipe...@gmail.com wrote:

 2010/11/1 Richard Lynch c...@l-i-e.com

  On Fri, October 29, 2010 7:47 pm, admin wrote:
   WTF is T_PAAMAYIM_NEKUDOTAYIM?
  
   This has to be THE most asked question by new php developers when they
   come across it. Can we please change the token name to T_DOUBLE_COLON
   so I don't have to hear about it constantly?
  
   Those that disagree don't do enough PHP support to know how often it
   is
   asked. it's worth it.
 
  -1
 
 
 Instead of renaming the token, I prefer to associate a literal string to
 each token, to have a legible error message, without the T_ being shown.

 For example, we could use in the Bison grammar file:
 %token T_PAAMAYIM_NEKUDOTAYIM ::

 So that the error message become:

 $ sapi/cli/php -r '::'
 Parse error: syntax error, unexpected :: in Command line code on line 1

 Instead of the known unexpected T_PAAMAYIM_NEKUDOTAYIM one.


+1 on implementing this so we don't have to wait for lemon.
While knowing how to use a search engine is good, it's even better to not
have to and save the time spent on it.


 --
 Regards,
 Felipe Pena

Re: [PHP-DEV] Type hinting

[André Rømcke]

Hi all:
On Wed, Jun 9, 2010 at 1:59 AM, Daniel Convissor 
dani...@analysisandsolutions.com wrote:

 Hi Lukas:

 On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
 
  Same deal as E_NOTICE. Either you care about them or you dont.

 Exactly.  The type hinting situation is unique.  It is something that
 applications will frequently want to handle gracefully in order to
 provide useful error messages.  A new error level is needed, as is an API
 / function to obtain the failed parameter names, desired type and passed
 type.


I personally don't get this error handling and weak type hinting discussion,
looks like a mix-up of type hints and input validation.
To me, type hints are a contract between an API and the consumer of the API,
reason being that it makes things a lot easier on the inside of that API
call and errors caused by misuse are caught early.
For those that don't want this contract, don't use it.. By default PHP will
behave just like you want, namely: type less.
But to me, that is not a good way for API's that are used by several
thousand developers that probably don't check the php doc every time they
use a function, and do something human; mistakes.

When PHP 5 added support for this, that made my day, even if it wasn't
complete.
It is one of the things that made PHP's OOP support a lot more on level with
other languages / platforms, and I think it is a strength that it behaves
like other platforms for those that want to use it.

So sorry, but I think Lukas'  Zeev's proposal is the wrong approach, it
will make this useless for the very people that wanted it in the first
place.

Example:
function fetchById( int $id, bool $asObject = true )

If weak type hints are accepted, type hints would be useless in this case as
consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm
not saying anyone would do this intentionally, but in a large application
you might not have full oversight and can unintentionally pass variables of
wrong type or in wrong order causing issues to surface much later as there
are no strict type checks that would detect the mistake immediately while
developing).

--

One solution (if weak type hinting is really needed) is to go back to Ilia's
proposal for virtual types and for example extend it with wint, wbool,
wstring, wfloat and similar (it could just as well be ~int, int_w or
int_cast for instance) for cases where you want to accept type by value.
This casting should be done with current type juggling rules for
consistency.
But adding cast support like this would make the whole catchable cast
error's discussion re appear. And those probably involves a lot more
overhead then handling such cases yourself inside your API functions using
exceptions, so I don't personally see any gain by this.

So to avoid that, I would say Derick's proposal to allow function foo(
(int) $bar) { } // auto-cast to int is superior as it will avoid that
discussion/issue, keep it simple  not be misunderstood as a means of input
validation.

- AR

Re: [PHP-DEV] Type hinting

[André Rømcke]

Hi Lukas!

On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote:


 On 09.06.2010, at 12:01, André Rømcke wrote:

  Example:
  function fetchById( int $id, bool $asObject = true )
 
  If weak type hints are accepted, type hints would be useless in this case
 as
  consumer can do something strange as fetchById( true, 'foo' ) (Obviously
 I'm
  not saying anyone would do this intentionally, but in a large application
  you might not have full oversight and can unintentionally pass variables
 of
  wrong type or in wrong order causing issues to surface much later as
 there
  are no strict type checks that would detect the mistake immediately while
  developing).


 please read RFC's you comment on (well the following was added to the RFC 2
 or maybe even 3 weeks ago):
 in your above example there would be data loss in the type cast and
 therefore there would not be silent auto casting.



http://wiki.php.net/rfc/typecheckingstrictandweak
I was assuming Option 1 for the example and the fact that E_STRICT like any
other error would just be logged somehow in most systems, hence not stop the
call from executing which would be an even bigger issue if it is an store()
function.



 anyway .. can we conclude this discussion? probably best if someone who is
 more or less impartial would handle the call fore vote and figure out some
 sensible way to let people vote on the various solutions that are proposed.


+1