Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

[Jakub Kubíček]

>From the RFC:


> var is therefore a limited subset of public.


No, this is wrong. `var` was here much much longer than `public`, therefore
`var` is not a subset of public, but rather `public` is _an extension_ of
`var`. The keyword `var` is also unique for it's semantics in the later
versions of the language viz. previous discussion:

- `var` represents not any certain visibility, it states that the
visibility of property is yet unspecified
- `var` can semantically also represent an internal dependency, as I have
described earlier

On 10 March 2016 at 22:44, Colin O'Dell  wrote:

> Hello all,
>
> I have completed my initial draft of the RFC to deprecate "var" in favor of
> "public": https://wiki.php.net/rfc/var_deprecation
>
> I would greatly appreciate any feedback on this RFC, especially with the
> following:
>
> - Ensuring that all major arguments for & against have been documented.
> - Any impact this may have on SAPIs, extensions, or the opcache.
> - Any assistance or guidance on creating the patch (I've never written C or
> worked with the core codebase before).
>
> If you'd like to read the pre-draft discussion it can be found here:
> https://wiki.php.net/rfc/mailing_list_discussion
>
> Regards,
>
> Colin O'Dell
>



-- 
Cheers,
Kubis

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

[Jakub Kubíček]

Hi Midori,

what about targetting this to the next PHP 7.x?

--
Kubis
On 10-Mar-2016 12:11 am, "Ryan Pallas"  wrote:

> On Wed, Mar 9, 2016 at 11:14 AM, Midori Kocak  wrote:
>
> > Hi all,
> >
> > Remember my question about ??= operator?
> >
> > Forgive my rookieness and let me introduce my first RFC here:
> > https://wiki.php.net/rfc/null_coalesce_equal_operator <
> > https://wiki.php.net/rfc/null_coalesce_equal_operator>
> >
>
> This looks great! I hope it makes it into the language for sure.
>
> One comment though, voting section should not be opened until after the
> required discussion period.
>

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Jakub Kubíček]

On 29 February 2016 at 15:25, Tony Marston  wrote:
> If "var" is automatically translated into "public", and has been since PHP 5
> emerged, and has been documented to behave in this way, then what does it
> cost to leave it that way? Answer: NOTHING!


Yeah. This is actually very true.

-- 
Cheers,
Kubis

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

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Jakub Kubíček]

Good morning Internals!

I am strongly AGAINST the removal of the `var` keyword from PHP
syntax. Though in general it's an alias of `public` (or it simply
‘acts’ as the `public` modifier), I see a difference in its
_semantics_. While the `public` modifier states anyone can change the
property, `var` is useful for marking internal properties which must
be public, but should not be manipulated by simply anybody e.g. in the
case of dependency injection:

fooService thanks to DI container
}
}

?>

This idea comes to me from using the Nette Framework, which handles DI
automatically and this way -- using `var` -- one can semantically
mark, which are the internally @inject'ed properties and differ them
from the `public` ones.


On 26 February 2016 at 15:16, Tony Marston  wrote:
> Sent: Thursday, February 25, 2016 12:58 PM
>>
>> To: Tony Marston
>> Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
>> Hi Tony,
>>
>> Thank you so much for your feedback.  You make some really good, valid
>> points.  If I may provide some responses to some of them:
>>
>>> Where is your proof? You say "not used by a major part of the community"
>>> which means that it is still being used by a minor part, but exactly how
>>> "minor"?
>>
>>
>> I downloaded and scanned the top 10,000 projects on Packagist (including
>> their dependencies).
>
>
> So you examined a bunch of source files in one location? What about those
> projects that aren't maintained on Packagist? Mine certainly isn't.
>
>> Only 4% use "var".  I looked closer into that 4% and found almost 2/3rds
>> were due to a handful of prominent packages being required as dependencies.
>> Adjusting these packages would drastically lower overall usage across the
>> ecosystem.  And because "var" is simply an alias for "public", making that
>> change would only require a bump in the patch version.
>>
>> I'm not 100% happy with my methodology because the dependencies are
>> counted multiple times.  When I have some time I'll revise my approach to
>> get more-accurate figures.
>
>
> The only way to obtain what could be called "accurate" figures would be to
> examine every PHP script ever written. What you have is nothing more than a
> small sample.
>
>>> it would take effort to take it out...
>>
>>
>>
>> Here's a simple PHP script which does this automatically:
>> https://gist.github.com/colinodell/5fb5e5d474674f294a38  Because "public" is
>> supported in 5.x and 7.x, programmers could run this script at any time
>> before the 8.0 release (assuming this proposed RFC passes and the programmer
>> wants their code to run on 8.0).
>>
>>> ...and amend the documentation
>>
>>
>>
>> I will happily make that change myself.
>>
>>
>>> while programmers expect new features to be added they do NOT expect old
>>> features
>>> to disappear. Once a piece of code has been written and has proved to
>>> work
>>> as designed it is expected to work with all future versions.
>>
>>
>>
>> I'm hoping that the automated upgrade script and advance warning would
>> help mitigate that impact.
>
>
> I, and others, will object to having to run any sort of conversion scripts
> just because you personally don't like the "var" keyword. It does no harm,
> so there is no benefit to be had by taking it out.
>
>
> --
> Tony Marston
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Thanks!

-- 
Cheers,
Kubis

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

[PHP-DEV] Class constants on object references have variable-inconsistent accessibility

[Jakub Kubíček]

Dear internals!

I have encountered an inconsistence, or rather a bug, in PHP's syntax.
The thing is, in PHP you can access constants defined on a
class using reference to an instance of this class, stored in
variable. So we have a code:



Which will nicely pass. But things will go wrong having a code trying
to access the same constant on an object of B stored in member
variable of class A -- let's see below:

b = new B;
var_dump($a->b::C === B::C); // Parse error: syntax error, unexpected
'::' (T_PAAMAYIM_NEKUDOTAYIM) in...

?>

Let me conclude that if there's access to class' constant using a
reference to an instance of the class, it should be possible with any
type of value-holder (so-called variable).

-- 
Cheers,
Kubis

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

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

[Jakub Kubíček]

Hi Larry!

2015-07-26 1:29 GMT+02:00 Larry Garfield la...@garfieldtech.com:
 Another point here is that 0 is a perfectly legitimate random number in many
 cases, so callers would need to do a === check, not just a boolean check.
What boolean check are you talkin' about? I've never seen a code
using e.g. strpos() like follows:

?php

if(!is_bool($pos = strpos('foobar', 'baz'))) {
// we are correct, use $pos' value somewhere
} else {
// strpos() produced a boolean, thus no 'baz' found in 'foobar'
}

?

Rather it is most frequently being done like below:

?php

if(FALSE !== $pos = strpos('foobar', 'baz')) {
// we are correct, use $pos' value somewhere
} else {
// strpos() produced a boolean, thus no 'baz' found in 'foobar'
}

?

I think in both cases you do a kind of boolean check.

 Especially as we're talking not about a user error but a your system is not 
 setup
 right so it will never work situation, as I understand it.
So, I generally agree with this approach. It is a better thing to
always fail closed if your system isn't set up, e.g. missing some
required things, to work properly. It's the same if your code uses
some vendor extension not included in the core by default -- it can
not work work properly without having this extension available.

I say +1 for raising a E_ERROR on random_int()/random_bytes() fail.


Best regards,
Kubo2, Jakub Kubíček

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

Re: [PHP-DEV] RFE to allow dirname($foo, 2)

[Jakub Kubíček]

Hi Scott!

2015-07-25 19:42 GMT+02:00 Scott Arciszewski sc...@paragonie.com:
 What's easier to read and less likely to result in bugs?

 require_once __DIR__ . '/../../../../autoload.php';

 or

 require_once dirname(__FILE__, 5) . '/autoload.php';
That's on everyone's own, but for me it's the first. However, it
couldn't be a disaster having ability to choose other option for
those, who are not familiar with relative paths. :-)


Best regards,
Kubo2, Jakub Kubíček

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

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

[Jakub Kubíček]

+1 for everything proposed here :-)


Kubo2


2015-07-02 9:59 GMT+02:00 Dmitry Stogov dmi...@zend.com:
 On Thu, Jul 2, 2015 at 3:26 AM, Bob Weinand bobw...@hotmail.com wrote:

  Am 29.06.2015 um 19:14 schrieb Andrea Faulds a...@ajf.me:
 
  Hi again,
 
  On 29 Jun 2015, at 18:02, Bob Weinand bobw...@hotmail.com wrote:
 
  Yes, it generally makes sense...
  Then I have other questions:
 
  - Why do we then still have a Warning? Either we have well-defined
 behavior, or we throw an exception. Well-defined behavior *plus* a warning
 is IMO non-sense.
 
  That’s weird, yeah. We don’t throw warnings for the math functions when
 you give them odd inputs, e.g. sin(INF) is just NAN, no warning.
 
  I think removing it would make sense.
 
  - Is it intentional for intdiv and % to throw an Exception instead of
 Error or some more specific DivisionByZeroError or similar? (yes, I know,
 Error is only very recent, but the question still needs to be asked).
 
  Hmm. Using Error might make some sense given it used to raise E_WARNING.
 I think DivisionByZeroError sounds like a good idea.

 Hey,

 I just committed that to master…

 But I noticed that intdiv(PHP_INT_MIN, -1) isn't very well suited for a
 DivisionByZeroError.

 What do you think about adding an ArithmeticError for that case (and
 making DivisionByZeroError subclass of it)?
 That ArithmeticError could then be reused for negative bitshifts, which
 would solve the question what to do with that too.


 I think we should introduce ArithmeticError, as you propose.

 Thanks. Dmitry.



 Thanks,
 Bob

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

Re: [PHP-DEV] Headsup: PHP7 feature freeze

[Jakub Kubíček]

2015-06-28 22:19 GMT+02:00 Anatol Belski anatol@belski.net:
 What is the benefit changing it? XHTML is a standard which is alive.

That's on every person's opinion. XHTML is currently not a standard,
XHTML is dead.

 But, there's for sure some code based on parsing the phpinfo() output, since 
 not everything is exported as a constant. IMHO having HTML5 in phpinfo(), 
 while being nice, doesn't justify itself breaking those codes.

Okay, that could be an argument. So I will rather focus on replacing
just these completely legacy things like a name or font etc. (plus
inline styles to make the HTML code more readable and
self-explainable).

I would argue that software can be updated, but... okay, let it be.


Best regards,
Kubo2, Jakub Kubíček

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

Re: [PHP-DEV] Headsup: PHP7 feature freeze

[Jakub Kubíček]

Hi RMs,

I have a pending change here http://github.com/php/php-src/pull/1301
which is however not ready to be merged yet. I am currently working on
it locally to do some more improvements for phpinfo(). I wanna ask you
if you consider it a feature and thus if I have to finish it before
the first beta is released if I wanna include it in PHP7 or rather to
target it against PHP 7.1.

Thanks for your reply.


Best regards
Kubo2, Jakub Kubíček


2015-06-25 17:03 GMT+02:00 Kalle Sommer Nielsen ka...@php.net:
 Howdy

 This is a  quick heads up that we plan to have the next release of
 7.0.0 be Beta 1, this marks a feature freeze and from there on, we
 will switch focus on to stabilization, regressions and other bug
 fixes.

 Beta 1 is schedule to be tagged and packaged on July 7th and released
 on July 9th which is a small 2 weeks from now to get any remaining
 changes of such in.

 If you are in doubt about whether or not your change would be
 considered a 'feature' or have any other questions, then feel free to
 mail us RMs or reply here.


 Thanks,
 Kalle, Anatol  Ferenc

 --
 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] Revisit trailing commas in function call parameters?

[Jakub Kubíček]

+1 for allowing trailing comma in every function call.


Regards,
Kubo2


2015-06-18 19:16 GMT+02:00 Florian Anderiasch m...@anderiasch.de:
 On 18.06.2015 08:25, Yasuo Ohgaki wrote:
 If people still consider it more harm- than useful then please don't flame
 me and I'll shut up again :-)


 PHP allows

 array(
   1,
   2,
   3,
 );

 therefore

 my_variadic_function(
foo,
bar,
qux,
 );

 is consistent behavior to me.

 If variadic functions allow this and normal functions don't (and by most
 PHP coding standards you'll format like this all the time because of 80
 chars limit I don't see how this is in any way consistent. It's still a
 function call after all and not an array.

 ~Florian

 --
 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] Migrating PHP classes to built in namespace

[Jakub Kubíček]

2015-06-12 10:10 GMT+02:00 Tony Marston tonymars...@hotmail.com:
 And what is the benefit in userland?

That is the question.

I think clean global namespace isn't enough argument, we can exist in
the current situation and considering the fact that most of the new
PHP applications have their own namespaces, it could probably make
more sense to reserve global namespace as *the PHP namespace*.


Regards,
Kubo2

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

Fwd: [PHP-DEV] Migrating PHP classes to built in namespace

[Jakub Kubíček]

/cc-ing internals, as I sent the message privately to Yasuo by mistake.

-- Forwarded message --
From: Jakub Kubíček kelerest...@gmail.com
Date: 2015-06-11 0:40 GMT+02:00
Subject: Re: [PHP-DEV] Migrating PHP classes to built in namespace
To: Yasuo Ohgaki yohg...@ohgaki.net


Hi.

This is weird and ugly what you're fabricating here. The PHP classes
should be all in global namespace. I am really against some
namespacing of them.

My € 0.02


Regards
Kubo2


2015-06-04 23:17 GMT+02:00 Yasuo Ohgaki yohg...@ohgaki.net:
 Hi Marc,

 On Thu, Jun 4, 2015 at 6:04 PM, Marc Bennewitz dev@mabe.berlin wrote:

 This one is not compatible with current code as you have to alias the PHP
 namespace to the root one before using full classes like \DateTime.


 Right.
 We are better to have PHP namespace for internal classes/functions first,
 then
 introduce as \ few years later. i.e. PHP classes/functions exist in both
 \ and \php
 namespace during migration period or we may user INI switch for migration.

 PS: I like a lower case php much more than upper case PHP ;)


 I'm neutral on this :)

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

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

Re: [PHP-DEV] Allow __toString() to throw exceptions

[Jakub Kubíček]

 Hi,


Hi Benjamin.

I have a question: is there any reason to throw an exception from
__toString, *other* than a non-recoverable error, which would denote that
the object, which the __toString method is called on, does not have any
meaningful string representation? Because if not, core implementation fully
serves its purpose throwing Fatal error now, even if it is non-standard way.

@aharvey said :

Should there ever be a Zend Engine 3, however, this could be revisited.

 ZE III is now here (AFAIK). So this have to be revisited :-*)*

Regards,
  Kubo2

[PHP-DEV] Replace dead and obsolete HTML in the core

[Jakub Kubíček]

Hi Internals,

I have recently made a patch[1] for PHP7 that replaces dead and obsolete
HTML code (like img border=0, a name=.../a vs. ...
id=.../... or XHTML's NET notation br / vs. HTML's br), mostly
being output by PHP itself (error messages, phpinfo() etc.), with
alternatives that are being used rather nowadays.

I would appreciate any feedback, as well as thoughts what else could be
included in the patch.


Thanks,
Kubo2

[1] https://github.com/php/php-src/pull/1301

Re: [PHP-DEV] Re: [RFC] Improved Error Callback Mechanism

[Jakub Kubíček]

+1 for this.


Best regards,
Kubo2

2015-04-24 15:10 GMT+02:00 Benjamin Eberlei kont...@beberlei.de:

 On Fri, Apr 24, 2015 at 12:24 PM, Olivier Garcia oliviergar...@php.net
 wrote:

  Greetings Internals,
 
  A few weeks ago, Patrick (patrickalla...@php.net) and I wrote a RFC
  [1] to improve the error callback mechanism and we just submitted a
  patch [2] - mostly written by Patrick - for review.
 
  Since our patch only modifies PHP's inner working and does nothing on
  the userland, we think it could be merged in PHP 7 and that the vote
  could be done using the 50% + 1 rule.
  Feel free to tell us if you're uncomfortable with it.
 
  If no problem is reported, we'll open the vote next week.
 

 I am very much in favour of this RFC. Hooking into the error handlers is a
 bit tricky right now when you have to assume that xdebug fiddles with your
 own hook.


 
  Kind regards
 
  [1] https://wiki.php.net/rfc/improved_error_callback_mechanism
  [2] https://github.com/php/php-src/pull/1247
 
  --
  Olivier Garcia
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 

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

[Jakub Kubíček]

Hey Alexander!

2015-04-22 10:26 GMT+02:00 Alexander Moskalev ir...@irker.net:

 Jakub, I think about static factory methods, but not sure if it will be
 great.
  I think using empty constructor more clear.


So we can add a setter, which, however, will return $this, to allow
chaining and prevent one redundant line of code:

?php

$fileBuffer = (new CURLFile)-setBuffer('some file contents');
// ($fileBuffer instanceof CURLFile) === true

But this looks a bit weird and for some people also confusing. Thus it
would be even better to have a static factory method, I think.


Best regards,
Kubo2

Re: [PHP-DEV] Closure::call() to access private data, really ?

[Jakub Kubíček]

My opinion is, that we simply have to change PHP closures' scoping to be
more similar with JavaScript functions' scope. That would solve the current
challenge pointed on by @jpauli, thus closure would have access to private
object's members only if it was defined in that object's class / method
definition, so then engine can know that it was programmers intention. I
mean something like this:

?php

$p = function() { $this-privateMember = new stdClass; };

class C {
private $privateMember;
private $closure;
function __construct() {
$this-closure = function() {
$this-privateMember = 32;
};
}
function callClosure() {
$this-closure-call($this);
}
}

$c = new C;
$c-callClosure(); // would succeed
$p-call($c); // Fatal error

?

What do you think about this kind of behavior?


Best regards,
Kubo2


2015-04-17 22:03 GMT+02:00 Marco Pivetta ocram...@gmail.com:

 On 17 April 2015 at 18:43, Ferenc Kovacs tyr...@gmail.com wrote:

  For the record this isn't exclusive to Closure::call, afaik the same
 thing
  is possible with Closure::bind() since 5.4
  http://3v4l.org/hlFS4
  And there are/were a decent amount of discussion (and AFAIR even hydrate
  libraries using this trick) about this, for example:
 
 
 http://ocramius.github.io/blog/accessing-private-php-class-members-without-reflection/
 

 Also note that this is the only way to access private properties by-ref
 (yes, I do need that for my horrible use-cases. No, don't ask about it.)

 Marco Pivetta

 http://twitter.com/Ocramius

 http://ocramius.github.com/

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

[Jakub Kubíček]

So, get directly to your questions:


 1) Can we still integrate this functionality to existing class CURLFile?


I think it would be possible, because like @smalyshev said, CURLFile
represents symbolic file, that is going to be uploaded with CURL. So my
suggestion would be creating a static factory method on this class,
something like `CURLFile::createFromBuffer( string )` or
`CURLFile::loadFromBuffer( string )`, which would create a CURLFile object
and initialize it with the passed contents („buffer“).

3) What do you think about unserialization for this class?
 a) Do not accept it (becouse object can contain very big file)
 b) Accept


I am for (un)serialization for this class. I think it's upon its user to
think whether to use it or not (because it could be a benefit, but there
are also situations, when it's not -- like that case, in which you have
very large file buffer).


Best reagards,
Kubo2


2015-04-18 23:35 GMT+02:00 Stanislav Malyshev smalys...@gmail.com:

 Hi!

  I have few questions for my pull request:
  https://github.com/php/php-src/pull/1217
 
  Short story: in some special cases we need to upload just created small
  file(s) by CURL. For example it's autogenerated image or pdf. And libcurl
  give for us this options: CURLFORM_BUFFER, CURLFORM_BUFFERPTR and
  CURLFORM_BUFFERLENGTH. My request about adding this options to curl php
  extension.

 I wonder if it's be hard to make streams work there... Then you could
 just pass php://memory or data:// as the file. Not sure about security
 implications though, needs some thinking.

  For basement I used class CURLFile, but can't find solution to use same
  class, because this class require file name on disc parameter in
  constructor. So I created new class, now it called as CURLBufferFile.

 While it does require file name as parameter, nobody says anything about
 disc there. So in addition to the above, you just could add
 setFileContents() API (or setFileBuffer? feel free to bikeshed :) that
 would make it take existing buffer instead of reading the file.

  So, my questions are:
  1) Can we still integrate this functionality to exists class CURLFile?

 I think, yes. Or at least we should try to. The meaning of CURLFile is
 not file on disk, it's something to be fed to CURL to be uploaded as
 a file, so having buffer does not violate the semantics.

  3) What do you think about unserialization for this class?
  a) Do not accept it (becouse object can contain very big file)
  b) Accept

 I don't see big issue in serializing/unserializing it. Yes, it can be
 big. So can be any string you can pass to unserializer, any object can
 contain tons of data, nothing different here. This object is just
 container for its values, so I don't see anything special here.
 --
 Stas Malyshev
 smalys...@gmail.com

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

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

[Jakub Kubíček]

I would rather appreciate run-time class properties initialization.


Best regards,
  Kubo2

2015-04-13 15:37 GMT+02:00 Johannes Ott m...@deroetzi.de:

 Hi,

 finally I managed to do my first RFC draft.

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

 I hope I have done everything correct so far and I'm looking forward to
 your feedback on it.

 As I already mentioned in the prediscussion thread here:

 For being my first change to the PHP core, I would be very happy, if
 someone of the old stager would help me with the implementation of
 this RFC if it is accepted.

 Regards

 --
 DerOetzi

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