Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

2018-09-20 Thread Christian Stoller
> -Ursprüngliche Nachricht-
> Von: Rowan Collins
> Gesendet: Mittwoch, 19. September 2018 23:47
> An: PHP Internals List
> Betreff: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
>
> On 19/09/2018 22:30, Marco Pivetta wrote:
> >
> > At least the approach without nullable properties will lead to a
> > Throwable when a read is attempted on an uninitialized object, which
> > is still better than nullability checks all over the place.
>
>
> Is it? Doesn't it just mean writing this:
>
> try {
> someFunction($object->propertyThatClaimsToBeNonNullable);
> } catch ( TypeError $e ) {
> ...
> }
>
> Instead of this:
>
> if ( ! is_null($object->propertyThatClaimsToBeNonNullable) ) {
> someFunction($object->propertyThatClaimsToBeNonNullable);
> } else {
> ...
> }
>
> For that matter, all I need to do is define someFunction as taking a
> non-nullable parameter, and I get the TypeError either way.
>
> Surely the point of a non-nullable property shouldn't be "it gives a
> slightly different error if it's not set", it should be "you don't have
> to worry about this not being set, because the language will enforce
> that somewhere". (And to cover your last point, that somewhere doesn't
> need to be the constructor, if requiring that is really such a big problem.)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

Just an idea: If an object is initialized without having all non-nullable 
properties initialized, one could store the instantiation place, and give this 
hint if an uninitialized property is accessed later.

Example:

// User.php

class User {
public Group $group;
}

// functions.php

function initUser() {
$user = new User(); // store this line and filename internally, because 
User::$group is uninitialized
return $user;
}

// index.php

$user = initUser();
echo $user->group->name; // Throws TypeError informing about access on 
uninitialized property and that it was initialized in file functions.php at 
line 3.


The TypeError still occurs but it makes it easy to find and fix the issue. And 
the same could be done with unsetting - save the place where an non-nullable 
property has been unsetted and inform the user where it happened if the 
unsetted property is accessed.

Best regards

Mit freundlichen Grüßen aus Paderborn

Christian Stoller
Web-Entwicklung

LEONEX Internet GmbH
Technologiepark 6
33100 Paderborn
Tel: +49 (5251) 4142-526
Fax: +49 (5251) 4142-501


HRB 8694 AG Paderborn
Geschäftsführer: Stephan Winter


LEONEX ist umgezogen: Bitte beachten Sie unsere neue Adresse sowie unsere neuen 
Rufnummern.
Wann dürfen wir Sie in unsere neuen Räumlichkeiten einladen?




[PHP-DEV] Re: Problem with overwriting private property value with ReflectionProperty

2016-09-19 Thread Christian Stoller
Von: Christian Stoller [mailto:stol...@leonex.de], Gesendet: Montag, 19. 
September 2016 10:27
Betreff: [PHP-DEV] Problem with overwriting private property value with 
ReflectionProperty

> Hi,
>
> I have spent several hours with a strange problem with reflection.
>
> There's an object of an external lib with a private field and I
> have to overwrite its values. Because there is no public method
> I am using ReflectionProperty like this:
>
> $reflProp = new \ReflectionProperty(Extension::class, 'classes');
> $reflProp->setAccessible(true);
> $reflProp->setValue($extension,['new', 'values']);
>
> var_export($extension->getClasses());
>
> The field is of type array and contains several entries. The problem
> is, that the private field has not been overwritten by
> `$reflProp->setValue()`. Instead it looked like, the array of the
> private field has been merged with my new array.
>
> I tried different things but nothing worked. I have tried to create
> a small script which could show the problem, but it wasn't reproducible.
>
> The last thing I tried was, to call
>
> var_export($reflProp->getValue($extension));
>
> instead of
>
> var_export($extension->getClasses());
>
> That returns exactly the correct value. So my question is if somebody
> could imagine why `$reflProp->getValue()` returns the value I am trying
> to set, but accessing the field with an object member method
> (getClasses) returns a merged array.
>
> I am using PHP 5.6.26 (x86, TS) on Windows 10.
>
> Best regards,
> Christian

Oh, sorry. I have found the problem now, after trying to overwrite the value 
with a string instead of an array. The object I had the problem with, has been 
extended by another class the the `getClasses` merged the field with another 
array.

Sorry for the noise.

Christian

Mit freundlichen Gr??en aus Paderborn

Christian Stoller
Softwareentwicklung

LEONEX Internet GmbH
Technologiepark 20
33100 Paderborn
Tel: 05251-14807-27
Fax: 05251-14807-30
HRB 8694 AG Paderborn
Gesch?ftsf?hrer: Stephan Winter


Erfolgreiche E-Business L?sungen von LEONEX
Erfahren Sie mehr unter www.leonex.de




[PHP-DEV] Problem with overwriting private property value with ReflectionProperty

2016-09-19 Thread Christian Stoller
Hi,

I have spent several hours with a strange problem with reflection.

There's an object of an external lib with a private field and I have to 
overwrite its values. Because there is no public method I am using 
ReflectionProperty like this:

$reflProp = new \ReflectionProperty(Extension::class, 'classes');
$reflProp->setAccessible(true);
$reflProp->setValue($extension,['new', 'values']);

var_export($extension->getClasses());

The field is of type array and contains several entries. The problem is, that 
the private field has not been overwritten by `$reflProp->setValue()`. Instead 
it looked like, the array of the private field has been merged with my new 
array.

I tried different things but nothing worked. I have tried to create a small 
script which could show the problem, but it wasn't reproducible.

The last thing I tried was, to call

var_export($reflProp->getValue($extension));

instead of

var_export($extension->getClasses());

That returns exactly the correct value. So my question is if somebody could 
imagine why `$reflProp->getValue()` returns the value I am trying to set, but 
accessing the field with an object member method (getClasses) returns a merged 
array.

I am using PHP 5.6.26 (x86, TS) on Windows 10.

Best regards,
Christian

Mit freundlichen Gr??en aus Paderborn

Christian Stoller
Softwareentwicklung

LEONEX Internet GmbH
Technologiepark 20
33100 Paderborn
Tel: 05251-14807-27
Fax: 05251-14807-30
HRB 8694 AG Paderborn
Gesch?ftsf?hrer: Stephan Winter


Erfolgreiche E-Business L?sungen von LEONEX
Erfahren Sie mehr unter www.leonex.de




AW: [PHP-DEV] [RFC] Allow loading extensions by name

2016-05-11 Thread Christian Stoller
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@php.net], Gesendet: Dienstag, 10. 
> Mai 2016 15:23
>
> Please read and comment :
>
> https://wiki.php.net/rfc/load-ext-by-name
>
> Regards
> 
> François
>

Why not just naming them *.so on all platforms and removing the "php_" prefix 
on Windows?

Apache modules on Windows also have the .so suffix.

Best regards
Christian


RE: [PHP-DEV] Access of protected members

2015-08-03 Thread Christian Stoller
From: Nicolai Scheer [mailto:nicolai.sch...@gmail.com], Sent: Monday, August 
03, 2015 11:39 AM
 
 Hi,

 just stumbled upon a strange issue.
 I always thought that protected/private member variables can only be
 altered from inside the object.

 This example shows, that this is not true:
 [...]
 Of course, I'm inside the right class, nevertheless, the object
 stored in $myself should not allow direct access to its members.

 Is this the expected behaviour? Code of this kind is used quite
 frequently for factory methods.


This is intended behavior. It is even possible to access private
methods and properties of another instance from the same type.
See example #3 on http://php.net/manual/en/language.oop5.visibility.php

The reason why this is possible is given, too:
 Objects of the same type will have access to each others
 private and protected members even though they are not the
 same instances. This is because the implementation specific
 details are already known when inside those objects.


Best reagrds
Christian


RE: [PHP-DEV] Serializing exceptions

2015-03-23 Thread Christian Stoller
From: Stanislav Malyshev [mailto:smalys...@gmail.com], Sent: Monday, March 23, 
2015 7:45 AM

 Hi!

 Maybe you can implement the __sleep method and just return the
 documented attributes (message, code, file, line).

That would be an option, but before going there, my question is - does
anybody need it, really?


Hi.

Symfony2 stores an `AuthenticationException` in the session,
when login credentials are invalid.

I think, exceptions should be serializable. One could strip
the objects from the backtrace and document it like that.

Christian


RE: [PHP-DEV] Consistent function names

2015-03-05 Thread Christian Stoller
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki, 
Sent: Thursday, March 05, 2015 9:45 AM

 On Thu, Mar 5, 2015 at 4:34 PM, Christian Stoller stol...@leonex.de wrote:
 From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki, 
 Sent: Thursday, March 05, 2015  7:21 AM

 For example, ctype extension has ctype_ prefix. It replaces
 is to ctype_.
 we may have isalpha alias as IEEE compliant name. There are many
 IEEE confirmed names already. Only small adjustments are needed.


 Changing ctype_alpha to isalpha would be inconsistent with is_numeric.

 I'm not going to change ctype_alpha to isalpha, but add IEEE complied name
 alias. So the manual page would have ctype_alpha as the main function,
 isalpha as IEEE complied alias.

Hi Yasuo,

I am not sure if you understood me correctly. If you add the alias `isalpha`, 
there will be people who will complain about new inconsistences, because there 
will be `isalpha` and `is_numeric`. Function names starting with is, having 
an underscore and some having no underscore.

I do not think that this mix will lead to less complains by developers.

Christian


RE: [PHP-DEV] Consistent function names

2015-03-04 Thread Christian Stoller
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki, 
Sent: Thursday, March 05, 2015 7:21 AM

 For example, ctype extension has ctype_ prefix. It replaces 
 is to ctype_.
 we may have isalpha alias as IEEE compliant name. There are many
 IEEE confirmed names already. Only small adjustments are needed.


Changing ctype_alpha to isalpha would be inconsistent with is_numeric.

Best regards



RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

2015-02-27 Thread Christian Stoller
From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015 
2:38 PM

 Hi Zeev,

 On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote:

  Drupal homepage:  One new E_DEPRECATED warning, which seems to catch a
  real bug, or at least faulty looking code:
$path = trim($path, '/');  // raises E_DEPRECATED, as $path is boolean
  false.
return $path;
 
  Drupal admin interface (across the all pages):  One  new E_DEPRECATED
  warning, which again seems to catch a real bug - stripslsahes() operating
  on a boolean.
 

 All those are due to a bug in substr(), that we see now only thanks to
 proper type identification. There is no reason for substr() to ever return
 a boolean. It really needs to be fix to always return a string.

 Damien

It is not a bug. FALSE as a return value of substr() is the identificator
for an error (e.g. invalid arguments), as it is stated in the documentation:

Returns the extracted part of string; or FALSE on failure, or an 
empty string. [1]

This is an example which shows, that Zeevs RFC helps to find bugs in
applications. Because here are given invalid arguments to the method. In
other languages for example Java, you'll get an IndexOutOfBoundsException [2]
if you are trying the same ;-)


  1: http://php.net/manual/en/function.substr.php
  2: 
http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#substring%28int,%20int%29



RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

2015-02-27 Thread Christian Stoller
From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015 
4:54 PM

 Hi Christian,

 On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller stol...@leonex.de wrote:
 It is not a bug. FALSE as a return value of substr() is the identificator
 for an error (e.g. invalid arguments), as it is stated in the documentation:
 [...]

 It is documented that way and it is not a bug are two very different 
 things.


That’s not true. Quoting Wikipedia A software bug is an error, flaw,
failure, or fault in a computer program or system that causes it 
to produce an incorrect or unexpected result, or to behave in 
unintended ways. [1]

In this case FALSE is an expected result and it is intended. And as
I said other languages are going the same way.


 In that case, the semantics of `substr()` are just wrong. It makes 
 a lot more sense for a sub-string function  to silently allow
 reading before the beginning and past the end  of a string.

Just because it makes more sense for you, it does not imply that
it makes more sense for everybody. In my opinion it makes sense to
return an error code if a function is called with invalid
arguments.

 This behavior is unpredictable, and as a consequence using `substr()` 
 properly would require a lot of painful and unnecessary up-front 
 checks. 

I agree with you, here. With the coercive patch this will lead to
More checks. But that's different from it is a bug ;-)

  1: http://en.wikipedia.org/wiki/Software_bug



[PHP-DEV] Blank page php.net/manual/en/class.uconverter.php

2014-12-12 Thread Christian Stoller
Hi.

When I am on the page http://php.net/manual/en/book.intl.php and click on 
“UConverter - The UConverter class”, I get linked to a blank page 
(http://php.net/manual/en/class.uconverter.php).

Same for http://php.net/mailing-lists.php

Something seems to be broken there.


Christian

P.S. Sorry for writing to the wrong list, but I am not sure what the website 
mailing list address was... and I can not open the list :-/


[PHP-DEV] RE: Blank page php.net/manual/en/class.uconverter.php

2014-12-12 Thread Christian Stoller

W dniu 2014-12-12 13:01, Christian Stoller pisze:
 Hi.

 When I am on the page http://php.net/manual/en/book.intl.php and click on 
 “UConverter - The UConverter class”, I get linked to a blank page 
 (http://php.net/manual/en/class.uconverter.php).

 Same for http://php.net/mailing-lists.php

 Something seems to be broken there.


 Christian

 P.S. Sorry for writing to the wrong list, but I am not sure what the website 
 mailing list address was... and I can not open the list :-/


It works again ;)


RE: [PHP-DEV] Only variables can be passed by reference

2014-12-04 Thread Christian Stoller

From: Andrea Faulds [mailto:a...@ajf.me], Thursday, December 04, 2014 9:33 AM

 On 4 Dec 2014, at 08:28, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 
 Hi all,
 
 I think we can get rid of this error now when literal is returned.
 The reason we have E_STRICT error is that legacy PHP didn't
 support this, I suppose.
 
 http://3v4l.org/8fISj

 Hmm, I think there’s some logic to having a warning anyway. 
 If a parameter is taken by reference, then it’s  presumably 
 going to be modified. So if you pass something that isn’t
 a variable (and therefore the modified result can’t be
 accessed) to a by-reference parameter, it doesn’t really
 make sense.
 --
 Andrea Faulds
 http://ajf.me/
 

I like Yasuo's proposal, because the developer who's passing a
non-variable by reference knows that the change will be lost. But this
could be desired as Yasuo's example shows.

I wished many times that this would be possible...



RE: [PHP-DEV] [RFC] Using objects as keys

2014-10-30 Thread Christian Stoller

From: Alexander Lisachenko [mailto:lisachenko...@gmail.com], Sent: Monday, 
October 27, 2014 11:18 AM

 Hello, internals!

 The name __hash is not final, I am open to using __toKey instead or any
 reasonable alternative, we may also include a couple of options in the
 vote if that will be a point of disagreement.

 I like this idea with custom hash implementation because spl_object_hash()
 is not reliable when objects are quickly created/destroyed, so hashes can
 be the same for several different objects. However, will it be better to
 introduce an interface for that? For example, Hashable can be a good name
 (like Traversable one). Default implementation then can be a simple trait
 that will be added later to the concrete class.


I like the idea introducing an interface for this functionality, instead
of adding a further magic method. But I think anything like hash or
hashable is confusing for users.

Maybe something like 

interface ArrayKeyConvertable
{
function toArrayKey();
}


Christian


RE: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7

2014-10-15 Thread Christian Stoller
 From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of 
 Julien Pauli, Sent: Tuesday, October 14, 2014 10:05 AM
 
 On Tue, Oct 14, 2014 at 9:25 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 ... like the hidden array element: http://3v4l.org/6uFqf
 ... like the hidden object property: http://3v4l.org/RPJXH

 The issue seems to be that array lookup always looks for numeric results
 when looking for numeric-like keys. But when adding property, the
 numeric check is not done since properties are not supposed to be
 numeric. Thus, when converting the object to array, the property named
 123 becomes inaccessible, because in array it is supposed to be under
 number 123.

 We could, of course, add numeric checks to properties, but it would slow
 things down only to serve very narrow use case with hardly any legit
 uses. We could also rewrite hashtable with numeric keys instead of
 string keys when doing conversion, but again that would be significant
 slowdown for a very rare use case. Not sure it's worth it.
 
 I agree that fixing a strange behavior - very little people know about
 and very few little people use in real case - involving performance
 penalty for any other use case ; should be a -1 of course.
 
 Let's say the behavior is here by design ;-)
 
 Julien.Pauli


If it is by design, it should be documented in 
http://php.net/manual/en/language.types.array.php#language.types.array.casting 
and maybe at a corresponding place on 
http://php.net/manual/en/language.types.object.php




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

2014-10-07 Thread Christian Stoller
From: Dan Ackroyd [mailto:dan...@basereality.com] ,Sent: Tuesday, October 07, 
2014 10:55 AM
 
 Stas wrote:

 The only issue I think we need to discuss is catch(Exception $e). Now it
 would catch much more than before, if we do no changes.

 It's not clear why would that be an issue - can you specify what the
 problem would be?

 Also, if we changed `catch(Exception $e)` to not catch all exceptions,
 than we would need to have another way of specifying that a catch
 block should catch all exceptions. Which would involve either making
 \Exception extend another even 'baser' Exception, or a hack to the
 syntax e.g. something like:
 
 catch($e) {
 // Catch without Exception type catches all exceptions
 // and confuses people.
 }

 cheers
 Dan
 Ack

We could make EngineException to be parent of the base Exception class.
And, if it is technically possible, it must be forbidden to extend
EngineException directly in userland.

This is just an idea. It would be a little bit strange if Exception is
not the base exception class ;) but it makes sense, because EngineException
is an exception of all other exceptions ^^

Christian


RE: [PHP-DEV] Little switch improvement: get the used variable

2014-09-25 Thread Christian Stoller



Mit freundlichen Grüßen aus Paderborn

Christian Stoller
Softwareentwicklung



LEONEX Internet GmbH
Technologiepark 20
33100 Paderborn
Tel: 05251-14807-27
Fax: 05251-14807-30
HRB 8694 AG Paderborn
Geschäftsführer: Stephan Winter

--
APPsolut nützlich - mit Apps neue Geschäftsmodelle  Geschäftsprozesse gestalten
Dienstag, 04. November 2014, mehr unter http://bit.ly/YXDNa3
--
-Original Message-
From: Rowan Collins [mailto:rowan.coll...@gmail.com], Sent: Thursday, September 
25, 2014 11:10 AM
 Rowan Collins wrote (on 24/09/2014):
 On 24/09/2014 22:33, Andrea Faulds wrote:
 On 24 Sep 2014, at 22:17, Rowan Collins rowan.coll...@gmail.com wrote:

 Perhaps rather than a magic function or constant, though, the switch 
 statement could be extended with an as argument, which would store 
 the evaluated expression into a normal variable, allowing nesting, 
 and easier optimisation of the engine where the feature isn't used. 
 Thus you could write this:

 switch( some_expression() as $switch_value ){
   case 1:
 do_something();
   break;
   //...
   default:
 throw new Exception('Undefined input: ' . $switch_value);
 break;
 }
 Incredibly, some brave soul has gone back in time and already 
 implemented this, when none of us was looking!

  switch($switch_value = some_expression()) {
  ...
  }


 Heh, now I feel like a fool for not thinking of that.

 Treating assigments as expressions just isn't something that jumps to 
 mind, I guess!


 Anyone have any thoughts on the use(operator) part, though?
 
 Am I missing something equally obvious there? Or just, it doesn't 
 interest people much as an idea?

Why should one add a new operator in that context if it is already
possible with assigments as expressions?

This makes the language more complex without getting any improvement.


RE: [PHP-DEV] Little switch improvement: get the used variable

2014-09-25 Thread Christian Stoller
From: Rowan Collins [mailto:rowan.coll...@gmail.com], Sent: Thursday, September 
25, 2014 12:31 PM
 
 Sorry, I was talking about this bit:
 
 Currently, switch always uses a loose comparison (==), so cannot 
 distinguish between case 3 and case 3.0. Occasionally, it would be 
 nice to switch on a strict comparison (===); but then I thought, why 
 stop there? What if you could use switch with any comparison operator?

 My idea is to give the switch() statement an optional use clause 
 (since that's an existing keyword) containing a single comparison operator

 See my earlier e-mail for examples and further details. Maybe I should 
 have given it its own thread so it was more visible; the idea has been 
 brewing for a while, I just thought this thread was a convenient place 
 to mention.

Ah, okay, sorry.
What do you think about that:

$value = 3;
switch (true) {
   case 3.0 === $value: break;
   case 3  $value: break;
   case 3  $value: break;
}

Christian


RE: [PHP-DEV] [RFC] Loop... or...

2014-09-22 Thread Christian Stoller

From: Leigh [mailto:lei...@gmail.com] Sent: Friday, September 19, 2014 11:57 PM

 Traditionally this is requested as a loop {} else {} structure,
 however due to the choice of keyword this causes significant BC
 problems.

 I have written an RFC presenting this feature as loop {} or {} along
 with how I intend to implement it. I have consulted with several core
 contributors as well as normal developers, and this seems to be the
 most BC-complete option.

I like this proposal as I am using this feature in Twig very often.
But I would really prefer using else instead of or, because it
is already common in the mentioned projects.
Maybe you could reconsider if it is really not possible to use else.

What about making the brackets for the loop block obligatory for
using this feature?

Christian


[PHP-DEV] Implementing interface method with child class in parameter def (Bug #42330)

2014-09-17 Thread Christian Stoller
Hello all,

I hope the subject is not misleading. Please look at the following code:

?php
class A { }

class B extends A { }

interface C {
function foo(A $a);
}

class D implements C {
public function foo(B $b) {

}
}

This code produces a Fatal error: Declaration of D::foo() must be
compatible with C::foo(A $a) in /xyz/inheritance.php on line 10
(see http://3v4l.org/l2M0f).

I don't get the reason for that behavior (and I could not find any
documentation about that, at least not at
http://php.net/manual/en/language.oop5.typehinting.php).

I have already found https://bugs.php.net/bug.php?id=42330 but Derick's
response does not help me and the linked file cannot be accessed
anymore.

I'd say that it is absolutely legal to define a more specialized
type in a child or implementing class, or would this have any bad
side effects?

Thanks and best regards
Christian


RE: [PHP-DEV] Implementing interface method with child class in parameter def (Bug #42330)

2014-09-17 Thread Christian Stoller
From: Johannes Schlüter [mailto:johan...@schlueters.de] 
 Thus having

 function bar(C $c) {
 $a = new A();
 $c-foo($a);
 }

 might work or might not work as $c might be an instance of D. Thus
 breaks the Liskov Substitution Principle
 http://en.wikipedia.org/wiki/Liskov_substitution_principle


Oh, now I see. Thanks fort he example, that helped ;)

Christian


RE: [PHP-DEV] [RFC] Disallow multiple default blocks in a single switch statement

2014-08-13 Thread Christian Stoller
From: Andrea Faulds [mailto:a...@ajf.me] 
Sent: Wednesday, August 13, 2014 11:43 AM
 
 Hi!

 On 13 Aug 2014, at 08:47, Ferenc Kovacs tyr...@gmail.com wrote:

 and I also think that this isn't an important enough issue to warrant a BC
 break (albeit this is the better kind of BC: probably doesn't effect too
 many people, and they will be clearly notified about the error at compile
 time) so I voted no based on this two thing.

 This isn’t really a BC break. Multiple default blocks didn’t actually
 work anyway, we just silently ignored extra ones.

 On 13 Aug 2014, at 09:13, James ja...@notjam.es wrote:

 I entirely believe this behavior is weird and should be removed. However,
 breaking backwards
 compatibility in a minor release because the incomplete spec says so is
 kind of odd.  A BC break
 is a BC break, which doesn't belong in a minor revision.

 It isn’t a BC break that will affect anyone. It fixes a parser bug.


If somebody unintentionally has multiple default blocks in his code and PHP 
is upgraded, he will get a parser error and his application will be broken.
This definitely IS a BC break.

But one could argue if this BC break will maybe help someone to find bugs
in his code ;-)



RE: [PHP-DEV] [VOTE] Move the phpng branch to master

2014-08-07 Thread Christian Stoller
From: Pierre Joye [mailto:pierre@gmail.com] 
 On Wed, Aug 6, 2014 at 3:45 PM, Andrea Faulds a...@ajf.me wrote:

 On 6 Aug 2014, at 14:26, Pierre Joye pierre@gmail.com wrote:

 For the exts I tried while I was testing/fixing phpng a couple of
 weeks ago, I'd to say that maintaining the same code base for phpng
 and 5.x is simply too hard, way too many APIs changes, many of them
 cannot be detected at compile time, introducing many many new #ifdefs
 along other things. I will maintain a separate branch. The only thing
 I worry about is how I will manage releases in pecl. I have no clean
 solution now, or maybe one release with two branches bundled. Separate
 releases could work too but I will try everything possible to do not
 have to do that, or to have to do that as it is really painful to do.
 Maybe I can manage to implement something in pickle to ease this work.
 Ideas welcome.

 Perhaps for these extensions, it is best to not make it work with
 both versions, but instead have a 5.x version and a phpng version, 
 and continue to maintain both separately? I wonder if that might actually 
 be less work than trying to keep a single version working on both.

 This is what I just said. But the problem is then how to release them.
 An extension will release 2.0.0, how do you release it? 2.0.0-7 and
 2.0.0 for 5.x? Packaging, branching, etc. will be painful too. The
 whole flow many projects uses now will have to change. This is
 something I have to think about, not sure what is the best solution
 yet.

 -- 
 Pierre

I'd say the best way is to create a new major version for the extension
branch which works with phpng.
So 2.0.0 for normal and 3.0.0 for phpng. This would make it possible
to maintain two branches for both versions. But I don't know if this is possible
with pecl.

Christian


RE: [PHP-DEV] Is fgetss() useless?

2014-07-29 Thread Christian Stoller
From: Maciej Sobaczewski [mailto:msobaczew...@gmail.com] 
 
 so... fgetss(). We have such a beautiful function in PHP. As it's 
 described in the manual: Get line from file pointer and strip HTML 
 tags. I'm wondering if it has any differences/advantages over using 
 just strip_tags(fgets($stream)).

 I'm going to write an RFC proposing deprecation and then removal of it, 
 but first I want to ensure that this function is as useless (IMHO) as I 
 think.

 Best regards,
 Maciej.

I like this proposal as I think that the number of different 
functions available for file reading is confusing for newcomers (at least it 
was for me, when I started with PHP ;-). 




RE: [PHP-DEV] PHP Language Specification

2014-07-23 Thread Christian Stoller
Rowan Collins wrote:
 Stas Malyshev wrote (on 22/07/2014):
 Alternatively, we could do a wiki maybe but the problem there is that it
 is hard to export (unless anybody knows wiki setups that can be easily
 exported into single document).

 Something like Wikipedia's Create a Book feature perhaps? [1] That can 
 be set up on any MediaWiki install with the right extensions. [2]

 It looks like DokuWiki (which I think wiki.php.net is running?) has a 
 similar plugin. [3] No idea if it's any good, but it looks like it's 
 reasonably actively maintained.

 [1] https://en.wikipedia.org/wiki/Help:Books
 [2] https://www.mediawiki.org/wiki/Extension:Collection
 [3] https://www.dokuwiki.org/plugin:bookcreator

Another idea would be a Git repository with the specification as markdown 
files. This would allow creating Pull Requests via GitHub.

Best regards,
Christian


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

2014-07-17 Thread Christian Stoller
 - I'd like to have E_CAST on all castings/type jugglings even if we do 
 not get scalar type hinting.

$var = 6.3;
$a = (int) $var;

Or $b = (bool) 1;

This is usual code and it could be wanted to losse information on casting. 
Triggering errors for that would be extremely annoying.


 - I propose to say/implement scalar parameter casting instead of 
 scalar type hinting with a casting syntax:
 
  function foo( (int) $i, ...)

That's bad to read, destroys the possibility to integrate method overloading 
one day in the future, and it is telling the wrong story.

If I have function moo(int $var) it shows that the method expects an integer.
If I have function moo((int) $var) it looks like: Give me whatever you want 
and I cast it into an integer.

Christian


RE: [PHP-DEV] [RFC] Constant Scalar Expressions

2013-08-14 Thread Christian Stoller
 Hello all,

 I'd like to propose a new RFC for 5.NEXT:

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

 This allows for defining constant expressions which are resolved at compile
 time.

What should that be for?

 const FOO = 1 + 1;
 const BAZ = HELLO  . WORLD!;

Why not just writing 

const FOO = 2;
const BAZ = HELLO WORLD!;

I think it makes code les readable. And if you want to give an important hint 
for the reader of the code, you can still write comments.


Best regards
Christian


[PHP-DEV] New syntax for multidimensional array loop with foreach

2013-06-27 Thread Christian Stoller
Hi internals,

during my current work I had an idea for shorter array iteration with foreach. 
I haven’t seen such a syntax until now, but I think it is easy to understand ;-)

Maybe you know the case where you have to iterate over all values of a 2D (or 
more) array:

$count = 0;
foreach ($array as $key = $innerArray) {
foreach ($innerArray as $innerKey = $value) {
$count += $value; 
// and do something with $key and $innerKey
}
}

The new syntax could make it shorter and faster to write... but maybe it's a 
bit too confusing?

$count = 0;
foreach ($array as $key = $innerArray as $innerKey = $value) {
$count += $value;
// and do something with $key and $innerKey
}

If the keys aren't needed, you can shorten it to:

$count = 0;
foreach ($array as $innerArray as $value) {
$count += $value;
}

What do you think?

--
Christian Stoller
LEONEX Internet GmbH


RE: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'

2013-06-26 Thread Christian Stoller
 But I think it looks a bit cleaner if the variable could be omitted,
 if it's not needed ;-)

 I don't think we need to change the language because Netbeans can't
 figure out how catch blocks work.

The Netbeans thing was just an example/addition.

 It's not used by you - which btw is usually not a good idea - if you've
 got an exception, you usually should somehow react to it - at least log
 it or something, that's what the exceptions are for, if the situation
 does not require special handling it shouldn't be an exception. But it

If you have an exception like `BadCredentialsException` and throw it during 
authentication if the user has entered wrong login data, than you have such a 
situation right?
But do you need any further information? No - in the catch block it may be 
enough to create a message for the user saying: wrong username or password.

Maybe you only use generic exceptions like `RuntimeException`. This can be an 
exception for almost everything. But if you have defined an exception for one 
special case, to interrupt your code, and catch such an exception you will 
always know why this exception has been thrown.
--
Christian Stoller
LEONEX Internet GmbH


[PHP-DEV] Moving PHP documentation to Git repository

2013-06-25 Thread Christian Stoller
Hi internals.

What do you think about moving the PHP documentation to a Git repository, 
mirrored on Github? Doing this would make it possible for everybody to extend 
the documentation easily by creating pull requests.

Today one has to get an SVN account to edit the docu or you have to use 
https://edit.php.net/ which does not work as expected (at least for me when I 
tried to update some German documentation). My changes have not been integrated 
for some months (I had to write an email to somebody of the doc team to apply 
the changes).

Symfony does it this way (see https://github.com/symfony/symfony-docs/) and I 
like it very much. It is really easy to extend/update parts of the docu which 
are not complete or outdated and I am sure that it is comfortable and 
timesaving for the doc team, too.

What do you think?

Best regards
Christian


RE: [PHP-DEV] Moving PHP documentation to Git repository

2013-06-25 Thread Christian Stoller
 That aside: resources is also the issue with the online editor. We have
 too few people working on docs, so in the end it doesn't make much
 difference if they don't have time to review edit.php.net or github.
 (while reviewing on edit.php.net has the benefit that it can directly
 validate the docbook, github can't)

The difference is that the Git repo with its translations could be viewed very 
easily via Github. And it is possible to comment on pull requests or discuss 
them.
Plus: Others can see what pull requests have been created already and you can 
see at a first glance how many open pull requests there are.

When I used the online editor, I changed something but I didn't know if it has 
been saved correctly (especially when the changes have not been deployed after 
weeks) or if there is somebody who has ever seen my changes. In Github you see 
what you have changed. That motivates to work on ;-)


Christian




RE: [PHP-DEV] idea: implement a Comparable interface

2013-05-08 Thread Christian Stoller
 On Tue, May 7, 2013 at 6:17 PM, Thomas Anderson zeln...@gmail.com wrote:

  It'd be nice if, when doing $objA  $objB, that that'd invoke
  $objA-__compareTo($objB) or something, much like Java's Comparable
  interface.
 

 Do you have examples of what this would be useful for? The two things that
 come to mind are DateTime (which can do this anyway as it's an internal
 class) and classes for bignums or something like that (which are probably
 also better implemented internally). So I'm not sure how much use there is
 for this.

 Nikita

I would like to see this feature in PHP! I often thought it would be very 
helpful. In days of PHP 5.2 I wrote a Date-Class similar to DateTime but with 
another API which should be the same as in C#. Comparing dates with 
``$date-compareTo($date2)  0`` is always hard to read and error-prone.

Another example: You have one database entity and a collection and you want to 
check if it is in the collection.

$dbEntity = ...;
$dbCollection = ...;

foreach ($dbCollection as $tmpEntity) {
if ($dbEntity-getId() == $tmpEntity-getId()) {
// ...
}
}

Instead you could write ``$dbEntity == $tmpEntity``. I think this is easier to 
read.

Of course you can say just syntetic sugar, but better readability of code 
helps developers a lot!

Best regards
Christian


FW: [PHP-DEV] DateTime-modify('tomorrow') Bug in PHP 5.3 on Linux

2013-03-13 Thread Christian Stoller
Hi Derick.

 The 5.3.14 result is correct. It was apparently a bug in earlier 5.3 
 versions.

 cheers,
 Derick

Thanks for this hint. So I guess that Debian has not ported the bugfix. Do you 
know the Git Revision of the patch? I would like to inform the PHP maintainers 
of Debian so that they can easily integrate the fix.

Thanks for help!


[PHP-DEV] DateTime-modify('tomorrow') Bug in PHP 5.3 on Linux

2013-03-12 Thread Christian Stoller
Dear internals,

I have a strange bug with DateTime-modify('tomorrow') in PHP 5.3 on Linux.
Code to reproduce:

?php
$d = new DateTime('2013-02-05 06:33:33');
echo $d-format('Y-m-d H:i:s').\n;

$d-modify('tomorrow');
echo $d-format('Y-m-d H:i:s').\n;
?

Current output on Windows with PHP 5.3.14:
2013-02-05 06:33:33
2013-02-06 00:00:00

Current output on Linux (Debian) with PHP 5.3.3-7+squeeze15:
2013-02-05 06:33:33
2013-02-06 06:33:33

Can somebody verify this behavior? Are there any information about that or is 
there already something in the bugtracker? I have googled but couldn't find 
anything about that.


Best regards
Christian Stoller


[PHP-DEV] data stream restricted by allow_url_fopen (Bug #47336)

2013-03-11 Thread Christian Stoller
Dear PHP developers,

I have run into a bug, which is open since 2009. It would be nice if you could 
look at https://bugs.php.net/bug.php?id=47336
It has been marked as “documentation problem”. But in my opinion the 
implementation should follow the documentation and allow fopen “data://” 
streams even if “allow_url_fopen” is set to “false”. Because it is not like 
opening a maybe manipulated URL.

It would be really nice if this bug could be fixed, soon.

Thanks in advance.

Christian Stoller



RE: [PHP-DEV] data stream restricted by allow_url_fopen (Bug #47336)

2013-03-11 Thread Christian Stoller
Hi Stas.

 I'm afraid it is not a good idea. allow_url_fopen is meant to protect
 file functions (fopen and friends) from being injected with
 user-controlled data - i.e. if you control the filesystem and you do
 fopen() under allow_url_fopen then it is reasonable to assume the data
 under that filename is under your control. However, data:// URLs clearly
 violate this assumption no less than http:// URLs do - data: just does
 it without even requiring a web server.

I am unsure whether I understand you. As far as I know with the data:// stream 
PHP does not access any file on the filesystem. It's just for transforming 
normal content in a variable to a resource, or not? So I do not see any risk. 
Maybe you can give me an example.


RE: [PHP-DEV] data stream restricted by allow_url_fopen (Bug #47336)

2013-03-11 Thread Christian Stoller
 If include of data urls is enabled, the attacker could do the same with
 file=data:image/png;base64,PD9waHAgZXZhbCgkX0dFVFsiY29kZSJdKTsgPz4K

Okay, I got it ;-)
So it would be nice if someone could update the documentation and set the bug 
to resolved

Thanks for your help.





RE: [PHP-DEV] PHP User Survey

2013-03-08 Thread Christian Stoller
   When do you upgrade to a new release of php e.g. 5.3 - 5.4
 - As soon as released
 - wait for the x.1 release
 - Once our OpCode cache supports it
 - When previous version hits EOL
 - When a new feature warrants the upgrade
 - When my Framework (Zend/Symfony/cake) or Software (Wordpress, Gallery,
   etc) requires it
  
  You should add:
  When my distro/hosting company upgrades.

 Also 'When my Framework supports it', as opposed to requires it.
 --
 Niel Archer

And: When my favourite stable Linux Distribution (Debian, Ubuntu, etc.) 
supports it.


Christian Stoller


RE: [PHP-DEV] I think that Function naming inconsistency bug deservers more attention

2013-01-28 Thread Christian Stoller
 You can write String class all by yourself, put it on github and once 
 virtually
 everybody is using it, we'd gladly discuss including it as a standard 
 extension.

In userland we can only do something like
$str = new String('my_string_class');
echo $str-length();

But that's useless.
It would be great if method calls on primitive types could be supported, like 
in Nikic' proof of concept (https://github.com/nikic/scalar_objects).

$str = 'my_string_class';
echo $str-length();

I would really like to see that in PHP. It's not only a nicer and shorter way 
to code but it would also be a solution for the function naming inconsistency 
;-)

Best regards
Christian



-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com] 
Sent: Saturday, January 26, 2013 7:39 PM
To: Thomas Bley
Cc: internals@lists.php.net; Rasmus Lerdorf
Subject: Re: [PHP-DEV] I think that Function naming inconsistency bug 
deservers more attention

Hi!

 So function aliases, new open tag and deprecation are bad. What about
 the String class?

Design it, write it and we'll see how it works. It's not like the
process should *start* with including it in PHP core. You can write
String class all by yourself, put it on github and once virtually
everybody is using it, we'd gladly discuss including it as a standard
extension.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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





RE: [PHP-DEV] [RFC] Reflection annotations reader

2013-01-09 Thread Christian Stoller
+1
I totally agree with Leigh.

In my opinion comments should not be abused for any logic. This is the reason 
I've never used the annotations for Doctrine, although it is a nice feature.


-Original Message-
From: Leigh [mailto:lei...@gmail.com] 
Sent: Wednesday, January 09, 2013 9:30 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Reflection annotations reader

In my opinion (for however little it matters), code is code, and comments
are comments. They should not mingle.

Annotations, if implemented, should have their own syntax that makes them
code, not an abstraction of a comment.

I already dislike the fact that getDocComment is there - in my opinion all
_comments_ should be discarded. That said, if people want to parse
annotations from doc block comments, getDocComment _is_ already there and
that is all they need to build a parser (imho). Annotations from doc blocks
could quite easily be an extension building on top of getDocComment.

I support annotations. As code, not comments.


On 9 January 2013 08:09, Peter Cowburn petercowb...@gmail.com wrote:

 On 9 January 2013 01:08, Rasmus Schultz ras...@mindplay.dk wrote:
  I've started working on a new proposal, but I'm getting hung up on the
  syntax - if we can't use angle brackets anymore, what can we use?
 Virtually
  every symbol on a standard US keyword is an operator of some sort, does
  that mean those are all out of the question?
 
  e.g. thinking of concrete possible basic syntax, neither of the following
  delimiters would work:
 
  [Foo('bar')]

 Why would this not work? I'm struggling to think of a place where one
 would want to use an annotation where it could be misinterpreted as an
 array literal.  If anything, the visual conflict or association with
 the array syntax is a good thing in my book: my brain parses it as an
 array of one or more annotations.

 
  Foo('bar')
 
  {Foo('bar')}
 
  And presumably none of the following would work either:
 
  ~Foo('bar')
  @Foo('bar')
  ^Foo('bar')
  *Foo('bar')
  Foo('bar')
  :Foo('bar')
 
  Can you think of anything that would work?
 
 
  On Tue, Jan 8, 2013 at 3:57 AM, Vladislav Veselinov
  v.veseli...@gmail.comwrote:
 
  Assume that you have this class with your proposed syntax:
 
  [SomeAnnotation('somevalue')]
  class Test {
 
  }
 
  This conflicts with the short array syntax. It looks like an array
  containing the result of the function 'SomeAnnotation' invoked with
  the parameter 'somevalue'.
  The only difference is the missing ; but relying on this to
  determine whether this is an annotation or not would be insane.
  I'd support such a decision but with other syntax.
 
  I like Guilherme's RFC. I just don't think that the syntax is very
 PHPish.
 
 

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




RE: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

2013-01-07 Thread Christian Stoller
Hi. I like the proposal of this RFC very much ;-)

But the way 'nullable' properties are defined is not very intuitive and 
unclean, in my opinion. Stas has already mentioned that. 
`public DateTime $date = NULL;` // this looks like the property is initialized 
with null, but it does not show that the property is 'nullable'

If type hinted properties are not allowed to be set to null, I would propose 
this way to make a property nullable:

public DateTime? $date;

In C# the question mark after a type is a short hand for a generic Nullable 
type.


-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com] 
Sent: Saturday, January 05, 2013 1:48 AM
To: Steve Clay
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors

On Sat, Jan 5, 2013 at 12:31 AM, Steve Clay st...@mrclay.org wrote:

 Would the following two be exactly functionally equivalent?

 public Foo $foo;

 public $foo {
 get;
 set(Foo $value) { $this-foo = $value; }
 }

 We should also consider how an author would allow type-hinted properties
 to accept NULL as a new value, in both proposals.


I think that's a very interesting question, thanks for bringing it up. I
think a good approach here would be the same one used for function argument
typehints, i.e. allow NULL when NULL is specified as the default value. So
`public DateTime $date;` would not allow an explicit NULL assignment,
whereas `public DateTime $date = NULL;` would.

Nikita


RE: [PHP-DEV] DateTime improvement

2012-12-21 Thread Christian Stoller
What about putting the new DateTimeImmutable (or whatever it will be called) 
into a PHP namespace?
Something like \PHP\Foobar\DateTimeImmutable

Is it generally planned to use namespaces for PHP classes? In my opinion it 
would be nice if the SPL and other classes would be put into such a namespace, 
too. Are there any plans to do that?


Christian Stoller


-Original Message-
From: Peter Cowburn [mailto:petercowb...@gmail.com] 
Sent: Friday, December 21, 2012 1:14 AM
To: Lazare Inepologlou
Cc: Larry Garfield; internals@lists.php.net
Subject: Re: [PHP-DEV] DateTime improvement

On 20 December 2012 20:06, Lazare Inepologlou linep...@gmail.com wrote:
 Of course, I have no idea if anyone in userspace is using
 DateTimeImmutable...

 Well, it seems unlikely, unless he is Yoda or French.

 I mean, in English, it is common to put the adjective in front of the noun,
 isn't it?

Class names aren't particularly subject, too strictly, to English
grammar rules.  Besides, the coding standards [1] dictate the class
name should be prefixed with the 'parent set' (e.g. extension name),
which in this case is not Immutable.

[1] https://github.com/php/php-src/blob/master/CODING_STANDARDS#L152


 Lazare INEPOLOGLOU
 Ingénieur Logiciel



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





[PHP-DEV] Improve DateTime Class

2012-12-10 Thread Christian Stoller
Hi internals,

what do you think about improving the modification functionality of the 
DateTime class. I always get a cold shiver, when I write something like this:
?php
$date = new DateTime()
$date-modify(‘+15 day’);

In my opinion it would be nicer if one could write:
$date-modify(15, DateTime::INTERVAL_DAY); // for adding 15 days
$date-modify(-15, DateTime::INTERVAL_DAY); // for subtracting 15 days

Even better would be to have methods like addDays(), addMonths(), etc.

This would make it cleaner and more readable. You do not have to do something 
like this:

$date = new DateTime();
$date-modify(getDaysToAddMethod() .  day); // I am not sure if a '+' sign is 
needed if the value is positive

And it is fully backward compatible.

Best regards
Christian



RE: [PHP-DEV] Improve DateTime Class

2012-12-10 Thread Christian Stoller
Hm... I know '$date-add(new DateInterval('P15D'));' is possible, but it has 
the same problem.

I have to write:

$date = new DateTime()
$date-add(new DateInterval('P' . getDaysToAddMethod() . 'D'));

I think it is very hard to read. Or is it just my personal point of view?


@Nikita: I know what you mean. But how would you add a month to a DateTime?


Best regards
Christian


-Original Message-
From: sebastian.krebs.ber...@gmail.com 
[mailto:sebastian.krebs.ber...@gmail.com] On Behalf Of Sebastian Krebs
Sent: Monday, December 10, 2012 1:23 PM
To: PHP internals list
Subject: Re: [PHP-DEV] Improve DateTime Class

Hi,

are you mabe just looking for

$date-add(new DateInterval('P15D'));

?


2012/12/10 Christian Stoller stol...@leonex.de

 Hi internals,

 what do you think about improving the modification functionality of the
 DateTime class. I always get a cold shiver, when I write something like
 this:
 ?php
 $date = new DateTime()
 $date-modify(‘+15 day’);

 In my opinion it would be nicer if one could write:
 $date-modify(15, DateTime::INTERVAL_DAY); // for adding 15 days
 $date-modify(-15, DateTime::INTERVAL_DAY); // for subtracting 15 days

 Even better would be to have methods like addDays(), addMonths(), etc.

 This would make it cleaner and more readable. You do not have to do
 something like this:

 $date = new DateTime();
 $date-modify(getDaysToAddMethod() .  day); // I am not sure if a '+'
 sign is needed if the value is positive

 And it is fully backward compatible.

 Best regards
 Christian




-- 
github.com/KingCrunch


RE: [PHP-DEV] RFC: ext/mysql deprecation

2012-11-20 Thread Christian Stoller
I just want to place a notice. Please visit 
http://de1.php.net/manual/de/function.mysql-query.php
The suggested alternatives are still not shown in all translated versions of 
the docs. I am sure that there are people who look in the docs but have never 
seen the suggestions before (like me)... I was forced to use PDO because of 
several frameworks and learned the advantages ;-)

Best regards
Christian


-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com] 
Sent: Tuesday, November 20, 2012 9:29 AM
To: Anthony Ferrara
Cc: Kris Craig; Adam Harvey; Chad Emrys; Patrick Allaert; 
internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation

hi Anthony,

On Mon, Nov 19, 2012 at 6:22 PM, Anthony Ferrara ircmax...@gmail.com wrote:
 Kris,


 By NEXT are you referring to 6.0 or 5.6?


 Whatever the release after 5.5 is. Be it 5.6, or 6.0, NEXT indicates the
 next temporal release...



 Also, can you add an option for raising E_DEPRECATED in 5.5 then removing
 support altogether in 6?


 That's already in there. That's what I mean by hard-deprecating it for
 5.5...

 And in either case, removal would happen one release after hard
 deprecation...

I do not follow the logic. It is too heavy to use the right
deprecation flag for the connect function only, but it is perfectly
fine to kill one of the most widely used extension in php history in a
minor version? I'd rather go with the flag and kill it in 6.

Cheers,
--
Pierre

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

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





RE: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

2012-11-14 Thread Christian Stoller
@ internal accessor method visibility / callability

I would prefer Type 1 because:
1. A programming language is made for those who use the language not for those 
who develop this language. What is the target group of PHP?
2. Why should I define a property protected $property { } and call it via 
-__getProperty() ? If I would like to do that, I can define public function 
__getProperty() { }
3. The feature provides *property accessors* and not magic method generators
4. Providing internal accessor method callability could make code less readable 
and more complex, without adding any plus
5. This magic behavior blows up documentation and will make the whole topic 
more complicated for beginners
6. What happens if I define protected $property { get() {...} } and 
protected function __getProperty() { } in one class? 

I hope that does not sound aggressive ;)

Best regards
Christian


-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com] 
Sent: Wednesday, November 14, 2012 2:28 PM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method 
Visibility / Callability

Been AWOL for a while and getting back to this, doesn't seem like any 
resolution has occurred, just the conversation has died down.

I would propose that:

1) Internal accessor methods that are defined are callable directly.
2) Said methods are not reflected or revealed by the engine (stack 
traces, reflection, etc would hide the engines implementation details)

I think that with the above, #1 makes it easy as no further changes are 
required to make that happen, they're already directly callable and #2 
jives with what *most userland programmers* would expect.

Anyone disagree?

On 10/26/2012 5:37 AM, Clint Priest wrote:
 I'm opening up several new threads to get discussion going on the 
 remaining being debated categories referenced in this 1.1 - 1.2 
 change spec:
 https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests 


 
 Some people are in favor of the internal functions being generated by 
 an accessor declaration should be invisible and non-callable directly. 
 Others are in favor of leaving them visible and callable.

 *Type 1 ( Userland Programmer )**
 *
 As a userland programmer, someone who cares nothing for how php 
 works, only how their own code works. If they define an accessor they 
 expect to see an accessor, reflection should reflect that there are 
 accessors and no other methods they did not explicitly define. If 
 they were to reflect on all of the methods of their class and see a 
 number of __getHours() they may be confused as to why or where this 
 function came from. From their perspective, they have defined an 
 accessor and how that accessor works on the inside is of no 
 importance to them and only seeks to complicate or confuse matters 
 when they are exposed to these implementation details of the php 
 language its-self. If you tried to set a value such as $obj?abc = 1 
 through an accessor which could not be set, you would probably want to 
 see an error like: Warning, cannot set Class?abc, no setter defined.

 *Type 2 ( Internals Programmer )**
 *
 As an internals programmer, you want nothing hidden from you. If an 
 accessor implements special __getHours() methods to work its magic, 
 then you want to see them, you want to call them directly if you so 
 choose. In effect you want nothing hidden from you. In this case you 
 probably don't even want Reflection to reflect accessors as anything 
 different than specially formatted and called methods on the class. 
 This can be understandable because you want all information available 
 to you. You would probably not be confused if you wrote $obj?abc = 1 
 and got back an error like Fatal Error: Class-__setAbc() function 
 does not exist.

 *Unfortunately 80 to 95% of all people who use PHP are of the first 
 type.**
 *
 Revealing these internal matters to them would only leave them 
 confused, possibly frustrated and likely asking about it to the 
 internals mailing list to answer (repeatedly).
 

 Thoughts?


-- 
-Clint

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





RE: [PHP-DEV] Object comparison

2012-11-09 Thread Christian Stoller
I would like to place a suggestion for comparing objects (I hope it is no 
problem, because this does not have anything to do with Sara's question - but 
it came to my mind when I read her mail). It would be a great feature if 
objects could be compared to other objects with ,  and the other 
operators, like it is suggested in RFC https://wiki.php.net/rfc/comparable
The DateTime class offers this feature - it would be nice if this could be made 
usable for userland classes/objects, too.

Best regards

Christian Stoller


-Original Message-
From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara Golemon
Sent: Friday, November 09, 2012 1:07 AM
To: PHP internals
Subject: [PHP-DEV] Object comparison

From: http://php.net/manual/en/language.operators.comparison.php

An object compared to anything which is not a bool, null, or object
should result in the object appearing to be greater than the other
operand.  For example:

$a = new stdClass();
$b = new stdClass();

var_dump(null  $a);
var_dump(false  $a);
var_dump(true == $a);
var_dump($a == $b);
var_dump(0  $a);
var_dump(1  $a); // false
var_dump(2  $a); // false
var_dump(foo  $a);
var_dump(2  $a);
var_dump(tmpfile()  $a);

Based on docs, I expect all nine of these to yield true, however in
practice, the two marked false come out as false because the RHS
object is converted to an integer (1), contrary to the docs.

Doc bug? Or code bug?  I'm inclined to call it a code bug, but wanted
others' thoughts.

-Sara

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





RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

2012-10-12 Thread Christian Stoller
Good hint, Nikita.
I like the feature of automatic properies. For the problems with unauthorized 
access: What about signing automated generated variables, so that they are 
only accessable through the property?

@Lester Caine: This properties do not break backward compatibility. If you do 
not want to use it, you do not need.
I like them because they offer an easy, short and well readable way to 
protected object or class variables.

Best regards
Christian Stoller


-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com] 
Sent: Friday, October 12, 2012 12:48 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest cpri...@zerocue.com wrote:
 Alright, here is the updated RFC as per discussions for the last few days:

 https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

 If you could read it over, make sure I have all of your concerns correctly 
 addressed and we can leave this open for the two week waiting period while I 
 make the final code changes.

 -Clint

I've been thinking a bit about the automatic properties again, and
noticed that I forgot to name one use case: Asymmetric accessor
visibility. Automatic properties may be useful in that context, so
that you can write public $foo { get; protected set; } (though they
don't necessarily need to be implemented as properties with auto
generated code, rather just properties with more detailed visibility
handling [a bit related to the stuff Amaury has been saying]).

Nikita

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





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

2012-10-09 Thread Christian Stoller
I personally like the idea by Denis Portnov with the magic constant __VALUE__ 
which goes along with other magic constants documented here 
http://www.php.net/manual/en/language.constants.predefined.php

But the advantage of the type hinting in the setter when we use set($value) 
should be weighted stronger. This is a great plus!
I would vote for Jazzer's 
 public $Hours {
 get() { ... }
 set($value) { ... }
 isset() { ... }
 unset() { ... }
 }

Best regards
Christian Stoller


-Original Message-
From: Jazzer Dane [mailto:tbprogram...@gmail.com] 
Sent: Tuesday, October 09, 2012 5:08 AM
To: Clint Priest
Cc: internals@lists.php.net; Aaron Holmes; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1

While I understand your concern with set being the only keyword using (),
and even agree it's a bit problematic, I see a big problem with using
$value.

Even if $value internally makes sense due to something along the lines of *
__setHours($value)* {} being equal to *set {}*, I think using $value
without it ever being defined in the developer's code is not at all a good
idea.
If I see $value in the code, I'll logically look for where it was defined,
and when I don't see it anywhere else in the code, things are going to very
quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a note in
the documentation. That's not enough.

A similar alternative to using $value that I'd argue would be much more
sensible would be to, as Denis mentioned, use either a magic constant or a
superglobal.

As I mentioned previously, I would rather go with the set($value) {} syntax.

Now, back to the part where I agree with you - the inconsistency wherein
set has () that denote it is a method but get, isset, and unset do not. I
see this inconsistency as something problematic enough to warrant a
solution.

We could go with the following:
public $Hours {
  get() { ... }
  set($value) { ... }
  isset() { ... }
  unset() { ... }
}

Yes, we now have a little bit more meat on the syntax, but in this case, I
don't think that it's all that bad. Here's two reasons why:
1) Adding parenthesis denotes that they are all functions - which they are!
If anything, adding parenthesis to all of them makes the implementation *
more* sensible.
2) It's *only* two more characters per function. On top of that, in my
opinion, this syntax is not ugly. In fact, as I just mentioned - this
implementation is arguably *more* consistent with the rest of PHP.

On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest cpri...@zerocue.com wrote:

 Seems a fair amount of people would like it with a definable parameter
 name, though the original RFC I based mine off of is more than 4 years old
 (mine is over a year old already).

 The $value is precisely chosen because it is exactly the way C# operates
 and the original author thought to keep it the same as another well-known
 language (why re-invent new syntax for no reason).

 That being said, javascript does indeed allow it, my concern then would be
 would we have the parameterized syntax only for set() and not get, isset or
 unset?

 If we do have them for all of them, it's a lot of extra characters with no
 real need.

 I definitely favor set($value) over a magic $Hours for the $Hours
 property, but I personally see no problem with the $value, it's not magic
 it's a locally defined variable.

 Internally, this:
public $Hours {
   get { ... }
   set { ... }
}

 Is implemented as standard functions, while they are hidden through
 reflection, these functions exist (as a result of the above example):

 public __getHours() { ... }
 public __setHours($value) { ... }

 Lastly, with regards to JavaScript style getters/setters, I don't think
 I've ever cared what the variable name was, I typically just do something
 like:

 set blah(x) { ... } -- x is fairly irrelevant and similarly the use of
 $value is fairly irrelevant.   Thoughts?

  -Original Message-
  From: Jazzer Dane [mailto:tbprogram...@gmail.com]
  Sent: Monday, October 08, 2012 5:32 PM
  To: Benjamin Eberlei
  Cc: Aaron Holmes; internals@lists.php.net
  Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
 
  I agree.
  It's more consistent than the $Hours solution and we don't have to add
 another superglobal or magic constant, which is quite nice. The
  typehinting is a big plus as well.
 
  On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei kont...@beberlei.de
 wrote:
 
   The set() one is really nice with the typehints.
  
   On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes aa...@aaronholmes.net
   wrote:
  
On 10/8/12 1:07 PM, Denis Portnov 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 isset
http://www.php.net/isset**($this-Seconds); }
 unsethttp://www.php.net/unset**  { unset