Re: [PHP-DEV] [RFC] Preloading

[Crocodile]

Just a side question: will the information on preloaded userland classes
and functions be available via php --rc / php --rf commands?

On Thu, Oct 25, 2018 at 10:42 AM Dmitry Stogov  wrote:

>
> On 10/25/18 10:47 AM, Michael Wallner wrote:
> > On 20/10/2018 15:06, Dmitry Stogov wrote:
> >>
> >> On Oct 19, 2018 5:20 PM, Sara Golemon  wrote:
> >> On Fri, Oct 19, 2018 at 3:17 AM Dmitry Stogov  wrote:
> >>> I would like to start discussion on a Preloadng RFC
> https://wiki.php.net/rfc/preload
> >>>
> >> 4) "In conjunction with ext/FFI (dangerous extension), we may allow
> >> FFI functionality only in preloaded PHP files, but not in regular
> >> ones."  Is there any interest in something like HHVM's HNI interface?
> >> FFI always sounds nice in theory, but complex types mean that a little
> >> bit of glue code is often a plus.
> >
> > As always when it comes to PHP and FFI I'd like to point out ext-psi [1]
> > which uses a different approach than other PHP FFIs until now.
> >
> > It parses PSI files at startup, which basically are C header files
> > augmented with the PHP userland interface decls, see for example the PSI
> > file for time.h [2]
> >
> > As you can see, marshalling from and to native types has been taken
> > seriously, and while we're capable of recursively unmarshalling e.g.
> > addrinfo structs [3] and handling sqlite callbacks [4] it's still not
> > possible yet for something like curl_easy_setopt.
> >
> >
> >
> > [1] https://github.com/m6w6/ext-psi
> > [2] https://github.com/m6w6/ext-psi/blob/master/psi.d/time.psi
> > [3] https://github.com/m6w6/ext-psi/blob/master/psi.d/netdb.psi#L70
> > [3] https://github.com/m6w6/ext-psi/blob/master/tests/netdb/gai001.phpt
> > [4]
> https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite.psi#L56
> > [4]
> https://github.com/m6w6/ext-psi/blob/master/tests/sqlite/sqlite001.phpt
> >
> >
> hi Michael,
>
> You made a great job developing ext-psi.
>
> But anyway, I more like my own FFI implementation (at least because it's
> simpler and it's mine).
>
> FFI::load() in conjunction with preloading, would provide functionality
> similar to PSI files loading on startup.
>
> In the future, I would like to push ext/FFI into core and integrate it
> with JIT (similar to LuaJIT way).
>
> In any case, this thread is about preloading, that is interesting by
> itself. FFI and JIT are the future scope.
>
> Thanks. Dmitry.
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
-- 
Best regards,
Victor Bolshov

Re: [PHP-DEV] Idea for better function callbacks (another syntactic sugar)

[Crocodile]

Sorry for a bunch of replies that simply have lost a lot of context.. I'll
try to summarize it all here:

> I believe the proposal for short lambas (which should get resurrected at
some
> point) would handle this case well enough as well as help a dozen other
> things.  To wit:
>
> array_filter($names, |$x| ==> trim($x))
>
> --Larry Garfield

 I don't think it's quite the same, and although I can agree that short
lambdas look better then normal in this context, I would still prefer
function::trim

> In my opinion "ideal" here is that our symbol tables are merged, so
> referring to "trim" in any context will resolve to at most one symbol

That sounds like a plan, and if there is a reasonable support for that,
then we could just have array_filter($arr, trim) - then its way better than
my proposal, and should also work with class methods.

> Right click on `function::trim` - Find Usages. Basically allows to find
all
> usages of a given function, including the callback usage.

Yeah, that was part of the idea, the other being to make these callbacks
semantically different from strings. Its just weird that a string is
callable, isn't it?

> And about methods? How it should works if I wants to call a method from a
> custom class? It should be function::CustomClass::someMethod?

My proposal would not work for methods. function::CustomClass::someMethod -
that doesn't look great at all, at least to me.

On Fri, Oct 26, 2018 at 10:01 PM Crocodile  wrote:

> My proposal would not work for methods. function::CustomClass::someMethod
> - that doesn't look great at all, at least to me.
>
>
> On Fri, Oct 26, 2018 at 6:08 PM David Rodrigues 
> wrote:
>
>> Em sex, 26 de out de 2018 às 09:30, Crocodile 
>> escreveu:
>>
>> > Hi internals!
>> >
>> > I have this idea of improving the way to specify callbacks for good old
>> PHP
>> > functions. For instance, I have this piece of code:
>> >
>> > ---
>> > array_filter($names, 'trim')
>> > ---
>> >
>> > The callback function name is specified as a string, which makes it
>> > not-so-obvious, although this is definitely a PHP way. An alternative
>> would
>> > be to rewrite this using a lambda:
>> >
>> > ---
>> > array_filter($names, function($name) { return trim($name); })
>> > ---
>> >
>> > This is way more wordy, and I bet most of us will go for the first
>> option.
>> >
>> > What if we had a more clear way of specifying those callbacks? I suggest
>> > the following:
>> >
>> > ---
>> > array_filter($names, function::trim)
>> > ---
>> >
>>
>> And about methods? How it should works if I wants to call a method from a
>> custom class? It should be function::CustomClass::someMethod?
>>
>>
>>
>> >
>> > It is, I believe, more clear then a simple string, just a bit more
>> wordy,
>> > and since "function" is a reserved word which never had anything to do
>> with
>> > "::", the lexer/parser could probably find a way to deal with this kind
>> of
>> > syntax (well, honestly, this part is totally unclear for me because I
>> only
>> > work with PHP from userland).
>> >
>> > Does anyone else find this could be a good addition? Or is it not worth
>> > considering? Or maybe I am missing some obvious pitfalls?
>> >
>> > Cheers,
>> > Victor
>> > --
>> > Best regards,
>> > Victor Bolshov
>> >
>>
>>
>> --
>> David Rodrigues
>>
> --
> Best regards,
> Victor Bolshov
>
-- 
Best regards,
Victor Bolshov

Re: [PHP-DEV] Idea for better function callbacks (another syntactic sugar)

[Crocodile]

My proposal would not work for methods. function::CustomClass::someMethod -
that doesn't look great at all, at least to me.

On Fri, Oct 26, 2018 at 6:08 PM David Rodrigues 
wrote:

> Em sex, 26 de out de 2018 às 09:30, Crocodile 
> escreveu:
>
> > Hi internals!
> >
> > I have this idea of improving the way to specify callbacks for good old
> PHP
> > functions. For instance, I have this piece of code:
> >
> > ---
> > array_filter($names, 'trim')
> > ---
> >
> > The callback function name is specified as a string, which makes it
> > not-so-obvious, although this is definitely a PHP way. An alternative
> would
> > be to rewrite this using a lambda:
> >
> > ---
> > array_filter($names, function($name) { return trim($name); })
> > ---
> >
> > This is way more wordy, and I bet most of us will go for the first
> option.
> >
> > What if we had a more clear way of specifying those callbacks? I suggest
> > the following:
> >
> > ---
> > array_filter($names, function::trim)
> > ---
> >
>
> And about methods? How it should works if I wants to call a method from a
> custom class? It should be function::CustomClass::someMethod?
>
>
>
> >
> > It is, I believe, more clear then a simple string, just a bit more wordy,
> > and since "function" is a reserved word which never had anything to do
> with
> > "::", the lexer/parser could probably find a way to deal with this kind
> of
> > syntax (well, honestly, this part is totally unclear for me because I
> only
> > work with PHP from userland).
> >
> > Does anyone else find this could be a good addition? Or is it not worth
> > considering? Or maybe I am missing some obvious pitfalls?
> >
> > Cheers,
> > Victor
> > --
> > Best regards,
> > Victor Bolshov
> >
>
>
> --
> David Rodrigues
>
-- 
Best regards,
Victor Bolshov

Re: [PHP-DEV] Idea for better function callbacks (another syntactic sugar)

[Crocodile]

Yeah, that was part of the idea, the other being to make these callbacks
semantically different from strings. Its just weird that a string is
callable, isn't it?

On Fri, Oct 26, 2018 at 6:03 PM Arvids Godjuks 
wrote:

> пт, 26 окт. 2018 г. в 18:57, Kalle Sommer Nielsen :
>
> > Den fre. 26. okt. 2018 kl. 17.43 skrev Larry Garfield <
> > la...@garfieldtech.com>:
> > > I believe the proposal for short lambas (which should get resurrected
> at
> > some
> > > point) would handle this case well enough as well as help a dozen other
> > > things.  To wit:
> > >
> > > array_filter($names, |$x| ==> trim($x))
> >
> > I still fail to see why it would be considered to have that over a
> > perfectly encapsulted string for a callback, using a lambda/closure is
> > just an extra runtime call for syntax sugar, that seems poor in my
> > eyes.
> >
>
> Right click on `function::trim` - Find Usages. Basically allows to find all
> usages of a given function, including the callback usage.
>
> >
> > What would be ideal here, would be for functions to be first class
> > citizens in callback contexts, like in C to avoid the quotation,
> > however it clashes with constants. A hack you can do in userland could
> > be something like:
> >
> > const trim = 'trim';
> > array_filter($names, trim);
> >
> >
> >
> > --
> > regards,
> >
> > Kalle Sommer Nielsen
> > ka...@php.net
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> --
> Arvīds Godjuks
>
> +371 26 851 664 <+371%2026%20851%20664>
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>
-- 
Best regards,
Victor Bolshov

Re: [PHP-DEV] Idea for better function callbacks (another syntactic sugar)

[Crocodile]

That sounds like a plan, and if there is a reasonable support for that,
then we could just have array_filter($arr, trim) - then its way better than
my proposal, and should also work with class methods.

On Fri, Oct 26, 2018 at 6:03 PM Levi Morrison  wrote:

> On Fri, Oct 26, 2018 at 9:57 AM Kalle Sommer Nielsen 
> wrote:
> >
> > Den fre. 26. okt. 2018 kl. 17.43 skrev Larry Garfield <
> la...@garfieldtech.com>:
> > > I believe the proposal for short lambas (which should get resurrected
> at some
> > > point) would handle this case well enough as well as help a dozen other
> > > things.  To wit:
> > >
> > > array_filter($names, |$x| ==> trim($x))
> >
> > I still fail to see why it would be considered to have that over a
> > perfectly encapsulted string for a callback, using a lambda/closure is
> > just an extra runtime call for syntax sugar, that seems poor in my
> > eyes.
> >
> > What would be ideal here, would be for functions to be first class
> > citizens in callback contexts, like in C to avoid the quotation,
> > however it clashes with constants. A hack you can do in userland could
> > be something like:
> >
> > const trim = 'trim';
> > array_filter($names, trim);
>
> In my opinion "ideal" here is that our symbol tables are merged, so
> referring to "trim" in any context will resolve to at most one symbol,
> *and* that we also have a short-closure syntax for times when there
> isn't a *perfect* function to use.
>
> In the next version of PHP I would really like to see some warnings
> for when symbol names get re-used so that in the future we can merge
> them with less of a BC break.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Best regards,
Victor Bolshov

Re: [PHP-DEV] Idea for better function callbacks (another syntactic sugar)

[Crocodile]

I don't think it's quite the same, and although I can agree that short
lambdas look better then normal in this context, I would still prefer
function::trim

On Fri, Oct 26, 2018 at 5:42 PM Larry Garfield 
wrote:

> On Friday, October 26, 2018 7:29:46 AM CDT Crocodile wrote:
> > Hi internals!
> >
> > I have this idea of improving the way to specify callbacks for good old
> PHP
> > functions. For instance, I have this piece of code:
> >
> > ---
> > array_filter($names, 'trim')
> > ---
> >
> > The callback function name is specified as a string, which makes it
> > not-so-obvious, although this is definitely a PHP way. An alternative
> would
> > be to rewrite this using a lambda:
> >
> > ---
> > array_filter($names, function($name) { return trim($name); })
> > ---
> >
> > This is way more wordy, and I bet most of us will go for the first
> option.
> >
> > What if we had a more clear way of specifying those callbacks? I suggest
> > the following:
> >
> > ---
> > array_filter($names, function::trim)
> > ---
> >
> > It is, I believe, more clear then a simple string, just a bit more wordy,
> > and since "function" is a reserved word which never had anything to do
> with
> > "::", the lexer/parser could probably find a way to deal with this kind
> of
> > syntax (well, honestly, this part is totally unclear for me because I
> only
> > work with PHP from userland).
> >
> > Does anyone else find this could be a good addition? Or is it not worth
> > considering? Or maybe I am missing some obvious pitfalls?
> >
> > Cheers,
> > Victor
>
> I believe the proposal for short lambas (which should get resurrected at
> some
> point) would handle this case well enough as well as help a dozen other
> things.  To wit:
>
> array_filter($names, |$x| ==> trim($x))
>
> --Larry Garfield

-- 
Best regards,
Victor Bolshov

[PHP-DEV] Idea for better function callbacks (another syntactic sugar)

[Crocodile]

Hi internals!

I have this idea of improving the way to specify callbacks for good old PHP
functions. For instance, I have this piece of code:

---
array_filter($names, 'trim')
---

The callback function name is specified as a string, which makes it
not-so-obvious, although this is definitely a PHP way. An alternative would
be to rewrite this using a lambda:

---
array_filter($names, function($name) { return trim($name); })
---

This is way more wordy, and I bet most of us will go for the first option.

What if we had a more clear way of specifying those callbacks? I suggest
the following:

---
array_filter($names, function::trim)
---

It is, I believe, more clear then a simple string, just a bit more wordy,
and since "function" is a reserved word which never had anything to do with
"::", the lexer/parser could probably find a way to deal with this kind of
syntax (well, honestly, this part is totally unclear for me because I only
work with PHP from userland).

Does anyone else find this could be a good addition? Or is it not worth
considering? Or maybe I am missing some obvious pitfalls?

Cheers,
Victor
-- 
Best regards,
Victor Bolshov

Re: [PHP-DEV] Re: A validator module for PHP7

[Crocodile]

It's almost always the case that you need to provide a meaningful feedback
about what exactly went wrong, rather then to just say "Failed!" While
simplicity is nice and you cannot overrate value of validation, this whole
thing is pretty much useless to me personally without this ability. Also, I
don't think it's a good idea to mix validation of scalar values, arrays and
even multiple arrays, in a single function.

On Tue, Mar 27, 2018 at 11:43 AM Yasuo Ohgaki  wrote:

> On Mon, Sep 4, 2017 at 3:33 PM, Yasuo Ohgaki  wrote:
>
> > Hi all,
> >
> > I spent a little time for a new input validation module. It's not totally
> > new module, but is based on Filter module's validation filter improvement
> > RFC in many ways. [1]
> >
> > As all of us knew already, input validation is the most important
> practice
> > in secure coding. [2][3] Yet, we don't provide usable feature out of box.
> > Sadly, almost all apps do not have proper input validation at trust
> > boundary. Unless we improve filter's validation, we need usable basic
> > validator by default. IMO.
> >
> > Since I didn't get much feedbacks during the RFC discussion, I cannot
> tell
> > what part is disliked. I guess too much features in filter is one reason.
> > Another is messed up codes/features by providing both "filter" and
> > "validation".
> >
> > Validator for PHP7 (validate module) gets rid of unneeded features. It
> > only has features for basic PHP data type validations. Validation
> > rule(spec) array is flexible enough. Almost any types of inputs could be
> > handled by multiple and nested validation rules.
> >
> > Except some minor features like overflow checks, most planned features
> are
> > implemented.
> >
> > https://github.com/yohgaki/validate-php
> >
> > Although the code is based on filter module's code, it's almost full
> > rewrite except validation logic came from filter. Please consider this as
> > under development module.
> > Feedbacks are appreciated.
> >
> > Regards,
> >
> > [1] https://wiki.php.net/rfc/add_validate_functions_to_filter
> > [2] https://www.securecoding.cert.org/confluence/display/
> > seccode/Top+10+Secure+Coding+Practices
> > [3] https://www.owasp.org/index.php/OWASP_Secure_Coding_
> > Practices_-_Quick_Reference_Guide
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
>
>
> I thought it would be nice to have PHP script version for
> Validate PHP. It a lot easier to modify API as needed. So
> I spend few hours last weekend.
>
> https://github.com/yohgaki/validate-php-scr
>
> Caution, I just wrote it and didn't debug it yet.
> However, it is good enough to play with, I suppose.
>
> API differs a little. This has more simplified parameter
> structure. Suggestions and comments are appreciated.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
-- 
Best regards,
Victor Bolshov

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Crocodile]

Nice one by Andreas Hennings, I think! I personally have also question on
deserialization of immutables. Is it going to be possible at all?

Another thing is that PDO will probably not be able to use FETCH_CLASS with
immutables, because of the way it initializes properties.

On Mon, Feb 26, 2018 at 4:13 PM Andreas Hennings <andr...@dqxtech.net>
wrote:

> Hello,
> my thoughts.
> For me personally the proposed feature would not be very useful.
> i like immutable objects. But for me the pattern of choice is private
> properties + constructor + optional "wither" methods.
>
> The "wither" methods create a clone of the object, then set a property
> value on the clone, then return the clone.
> This would already not work if the property is marked as immutable
> with the proposed feature.
>
> Also static method constructors that write directly on the object
> would not work, because technically they are not part of the
> constructor.
>
> For private properties the proposed feature would add little benefit.
> Any private property can be made practically immutable by writing the
> class accordingly: Not having setters, etc.
>
> Where this feature would become useful is if someone prefers public
> properties over getter methods.
> But again, this would prevent any unconventional constructor, like
> withers or static factories.
>
> I think a better and more useful feature would be read-public,
> write-private.
> Maybe like this? https://wiki.php.net/rfc/readonly_properties
> (For some reason I cannot open the RFC wiki pages. Maybe they are down?)
>
> This would achieve the same goal: Making a property practically immutable.
> But it would still allow unconventional constructors.
> It would be the implementor's job to decide which method should be
> allowed to modify a property, and which shouldn't.
>
>
>
> On 26 February 2018 at 13:52, Silvio Marijić <marijic.sil...@gmail.com>
> wrote:
> > Currently the build is failing in some parts of the codebase that are
> > obviously affected in some way.
> > I ran valgrind for couple of failing tests and I got numerous reports
> about
> > memory leaks and conditional jumps over uninitialized values.
> > Not sure what is the reason for that, I had merge conflict with upstream
> > master couple days ago, might be a reason.
> >
> > I would appreciate if anyone could give me hand on this ?
> >
> > On Feb 26, 2018 1:48 PM, "Silvio Marijić" <marijic.sil...@gmail.com>
> wrote:
> >
> >> Currently the build is failing in some parts of the codebase that are
> >> obviously affected in some way.
> >> I ran valgrind for couple of failing tests and I got numerous reports
> >> about memory leaks and conditional jumps over uninitialized values.
> >> Not sure what is the reason for that, I had merge conflict with upstream
> >> master couple days ago, might be a reason.
> >>
> >> I would appreciate if anyone could give me hand on this ?
> >>
> >> On Feb 26, 2018 1:44 PM, marijic.sil...@gmail.com wrote:
> >>
> >> Yes, I've also took that into consideration when choosing keyword.
> >>
> >> On Feb 26, 2018 11:35 AM, "Crocodile" <crocodil...@gmail.com> wrote:
> >>
> >> Is "value" or "immutable" going to become a new reserved word? Ain't we
> >> going to have some BC breaks because of that? If so, then "value" is
> going
> >> to bring more BC breaks then "immutable".
> >>
> >> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones <pmjone...@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> > On Feb 25, 2018, at 12:59, Silvio Marijić <marijic.sil...@gmail.com>
> >>> wrote:
> >>> >
> >>> > Here is link to tweet https://twitter.com/SilvioMari
> >>> jic/status/965564630071300096
> >>>
> >>> After having read that, I think "immutable" is still perfectly
> reasonable.
> >>>
> >>>
> >>> --
> >>> Paul M. Jones
> >>> pmjo...@pmjones.io
> >>> http://paul-m-jones.com
> >>>
> >>> Modernizing Legacy Applications in PHP
> >>> https://leanpub.com/mlaphp
> >>>
> >>> Solving the N+1 Problem in PHP
> >>> https://leanpub.com/sn1php
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>> --
> >> Best regards,
> >> Victor Bolshov
> >>
> >>
> >>
> >>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Best regards,
Victor Bolshov

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Crocodile]

Is "value" or "immutable" going to become a new reserved word? Ain't we
going to have some BC breaks because of that? If so, then "value" is going
to bring more BC breaks then "immutable".

On Sun, Feb 25, 2018 at 8:02 PM Paul Jones  wrote:

>
>
> > On Feb 25, 2018, at 12:59, Silvio Marijić 
> wrote:
> >
> > Here is link to tweet
> https://twitter.com/SilvioMarijic/status/965564630071300096
>
> After having read that, I think "immutable" is still perfectly reasonable.
>
>
> --
> Paul M. Jones
> pmjo...@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Best regards,
Victor Bolshov

Re: [PHP-DEV] A validator module for PHP7

[Crocodile]

In most cases users would like more than just valid/invalid, i. e. which
particular rule(s) failed and also human-readable error messages. As of
simple validation that is almost always at hand, filter_* functions do a
good job, although I agree that they could be better. I, for one, would
like to see a full-featured validation as part of PHP. However, this RFC
only looks like a slightly better version of filter_* functions, that is,
the new module will provide almost the same functionality but with a
different interface. I would vote against it.

On Mon, Sep 4, 2017 at 2:54 PM Rowan Collins 
wrote:

> On 4 September 2017 07:33:41 BST, Yasuo Ohgaki  wrote:
> >Hi all,
> >
> >I spent a little time for a new input validation module. It's not
> >totally
> >new module, but is based on Filter module's validation filter
> >improvement
> >RFC in many ways. [1]
>
> Hi Yasuo,
>
> Thanks for tackling this. I do think the current filter module is user
> unfriendly and it would be great to have something better. A couple of
> quick thoughts based on your README:
>
> - The use of nested arrays keeps things simple in one sense, but the deep
> nesting can get confusing. I wonder if a ValidationRule class would make
> the distinction between parameters and references to existing rules
> clearer. This would also give you a natural home for validating the
> validation rules themselves (probably by throwing an exception in the
> constructor).
>
> - A minor point, but most style guides would suggest function names should
> be verbs, not adjectives, so "validate()" rather than "valid()".
>
> - Is there a use case for valid_id() or is it a temporary debugging thing
> that won't be in the final version?
>
> In general, I like the idea, but would have to play around a bit to see if
> it felt easy to use in real world situations.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Best regards,
Victor Bolshov

Re: [PHP-DEV] New constants in DateTime

[Crocodile]

Well, actually, that's a good reason for not having interval constants in
the core. Still think though that SQL formats would be a nice addition ;-)

On Thu, Mar 2, 2017 at 4:57 PM Andreas Heigl <andr...@heigl.org> wrote:

>
> Am 02.03.17 um 16:46 schrieb Crocodile:
> > While I agree with everything you're saying, I also think it could still
> be
> > worth it to have those constants in core for the following reasons:
> >
> > 1. MINUTE, HOUR and DAY are particularly often used, 99.999% of the time
> in
> > a context where it does not matter if a minute has 60 seconds or not, or
> if
> > a day has 24h or not. Particularly often used to specify cache lifetime,
> > for example.
> IMO they then should be part of the caching (or whatever)-implementation
> and not of DateTime. As *when* they are part of DateTime they will be
> used in a DateTime-context *where they shouldn't be used*!
>
> > 2. It's surely easy to implement them in userland but that would require
> > either global constants or a class in userland specifically for that
> > purpose. Both ways are easy, but these constants I see in virtually any
> > project, so for me it would be handy to have them in DateTime.
>
> When you need them use a Constant-Class or create a composer package
> that contains your constants and require that.
>
> https://3v4l.org/5MW7O
>
> That's much more extensible than having them in the core and needing to
> maintain them for everyone…
>
> But as I said: just my 0.02€
>
> Cheers
>
> Andreas
> >
> > But of course, I don't see it as a must-have, just as nice-to-have.
> >
> > Cheers,
> > Victor
> >
> > On Thu, Mar 2, 2017 at 4:03 PM Andreas Heigl <andr...@heigl.org> wrote:
> >
> >> Hi Victor.
> >>
> >>
> >> Am 02.03.17 um 15:48 schrieb Crocodile:
> >>> Hello internals,
> >>>
> >>> A similar question should have been asked already but I haven't found
> >>> anything so far when googling: I think DateTime class should have the
> >>> following constants in addition to those already existing:
> >>>
> >>> const SQL = "Y-m-d H:i:s";
> >>> const SQL_DATE = "Y-m-d";
> >>> const SQL_TIME = "H:i:s";
> >>> const SECOND = 1;
> >>> const MINUTE = 60;
> >> Not every minute has 60 seconds.
> >>> const HOUR = 3600;
> >> See above!
> >>> const DAY = 86400;
> >> Not every day has 86400 seconds. For one see the comment on MINUTE and
> >> also there are days that have more or less than 24 hours (DST)
> >>
> >> Therefore I wouldn't want to see those constants (that are also very
> >> easy to put up in userland - even though they aren't correct) in the
> >> PHP-Core.
> >>
> >> And as the SQL-Constants are also easily to implement in userland I'm
> >> not sure it makes to add them to the core…
> >>
> >> But that's just my 0.02€
> >>
> >> Cheers
> >>
> >> Andreas
> >>
> >>
> >> --
> >>   ,,,
> >>  (o o)
> >> +-ooO-(_)-Ooo-+
> >> | Andreas Heigl   |
> >> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> >> | http://andreas.heigl.org   http://hei.gl/wiFKy7 |
> >> +-+
> >> | http://hei.gl/root-ca   |
> >> +-+
> >>
> >> --
> > Best regards,
> > Victor Bolshov
> >
>
>
> --
>   ,,,
>  (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> | http://andreas.heigl.org   http://hei.gl/wiFKy7 |
> +-+
> | http://hei.gl/root-ca   |
> +-+
>
> --
Best regards,
Victor Bolshov

Re: [PHP-DEV] New constants in DateTime

[Crocodile]

While I agree with everything you're saying, I also think it could still be
worth it to have those constants in core for the following reasons:

1. MINUTE, HOUR and DAY are particularly often used, 99.999% of the time in
a context where it does not matter if a minute has 60 seconds or not, or if
a day has 24h or not. Particularly often used to specify cache lifetime,
for example.
2. It's surely easy to implement them in userland but that would require
either global constants or a class in userland specifically for that
purpose. Both ways are easy, but these constants I see in virtually any
project, so for me it would be handy to have them in DateTime.

But of course, I don't see it as a must-have, just as nice-to-have.

Cheers,
Victor

On Thu, Mar 2, 2017 at 4:03 PM Andreas Heigl <andr...@heigl.org> wrote:

> Hi Victor.
>
>
> Am 02.03.17 um 15:48 schrieb Crocodile:
> > Hello internals,
> >
> > A similar question should have been asked already but I haven't found
> > anything so far when googling: I think DateTime class should have the
> > following constants in addition to those already existing:
> >
> > const SQL = "Y-m-d H:i:s";
> > const SQL_DATE = "Y-m-d";
> > const SQL_TIME = "H:i:s";
> > const SECOND = 1;
> > const MINUTE = 60;
> Not every minute has 60 seconds.
> > const HOUR = 3600;
> See above!
> > const DAY = 86400;
> Not every day has 86400 seconds. For one see the comment on MINUTE and
> also there are days that have more or less than 24 hours (DST)
>
> Therefore I wouldn't want to see those constants (that are also very
> easy to put up in userland - even though they aren't correct) in the
> PHP-Core.
>
> And as the SQL-Constants are also easily to implement in userland I'm
> not sure it makes to add them to the core…
>
> But that's just my 0.02€
>
> Cheers
>
> Andreas
>
>
> --
>   ,,,
>  (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> | http://andreas.heigl.org   http://hei.gl/wiFKy7 |
> +-+
> | http://hei.gl/root-ca   |
> +-+
>
> --
Best regards,
Victor Bolshov

[PHP-DEV] New constants in DateTime

[Crocodile]

Hello internals,

A similar question should have been asked already but I haven't found
anything so far when googling: I think DateTime class should have the
following constants in addition to those already existing:

const SQL = "Y-m-d H:i:s";
const SQL_DATE = "Y-m-d";
const SQL_TIME = "H:i:s";
const SECOND = 1;
const MINUTE = 60;
const HOUR = 3600;
const DAY = 86400;

Easy-to-make feature that will be useful to a lot of PHP devs, I believe.

The exact naming of SQL_* constants is subject to dsicuss.

Best regards,
Victor
-- 
Best regards,
Victor Bolshov

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

[Crocodile]

What about PDO's fetch-mode PDO::FETCH_CLASS? Apparently, it first fills in
properties and then calls the constructor. Seems unlikely that the new
behavior for uninitialized properties will cause a problem here, but
sometimes weird things happen. And this is another thing to check.
I also fully support Johannes Schlüter with the reference thing. Binding by
reference to a query, passing by reference to any sort of function might
happen here and there, and the developer will have to find workarounds in a
place which otherwise would be straighforward.

Having said that, I +1 the idea of typed properties (well, my internals
karma does not give much weight to this anyway ;-) ).

On Thu, Mar 17, 2016 at 9:11 AM Benjamin Eberlei 
wrote:

> On Wed, Mar 16, 2016 at 5:36 PM, Phil Sturgeon 
> wrote:
>
> > Hello everyone,
> >
> > I have completed the draft for an RFC, to add Typed Properties. The
> > patch has been written by the one and only Joe Watkins.
> >
> > https://wiki.php.net/rfc/typed-properties
> >
> > I would really appreciate constructive feedback on this RFC, with a
> > few areas especially:
> >
> > 1. How scared are we that integers can be expanded to floats on runtime?
>
>
> > 2. This whole temporary nullability situation, where unset properties
> > will error on attempted usage if not set. Should they instead error
> > after the constructor has been called if they are still not holding a
> > value?
> >
> > 3. Weak vs Strict. Right now this is entirely strict, with no
> > declare() to change mode. Reasons for this vary, from various sources,
> > but include "Not sure how to implement it" and "Well people should not
> > be using properties as part of their public API".
> >
> > Help on 3 would be appreciated.
> >
> > Also let's please avoid "PHP IS TURNING INTO JAVA" and the other
> > rather common rhetoric. Strict Type Hinting might have been seen as a
> > battleground for fans of strict and fans of weak to fight through a
> > keyboard, but this RFC will not be the repeat.
> >
> > We'll have a nice, orderly, constructive conversation about this RFC,
> > and improve the patch as you all provide feedback.
> >
> > Let me know what you think folks!
> >
>
> Thanks for the RFC. I love it.
>
> Some points:
>
> 1. You should really try not to open any can of worms with regard to other
> already defined parts of the language:
>
> - Assume type juggling is a given, use that exact same rules
> - Assume strict/weak is a given, don't try to change this.
> - Document how public int $var; works with regard to default type,
> explicitly define it outside the scope of nullable types and delegate
> decision forward to a potential RFC in that area.
>
> Regarding your bullets then:
>
> 1. This point is outside the scope of this RFC, it might be relevant when
> we discuss changing type juggling to be more consistent.
> 2.  This is propably the critical point of this RFC, I think given how
> public function foo(int $i) forces type juggling, typed properties should
> force juggling to. This must be after the constructor, because public
> stdClass $foo; would otherwise never work.
> 3. Weak vs strict: Outside of this RFC, assume that it is strict when
> declared, otherwise weak for consistency with the status quo.
>
>
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
-- 
Best regards,
Victor Bolshov

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

[Crocodile]

Just an idea of a syntax for nullable properties. What about:
/**
 * Can be null
 */
public int null $foo;
/**
 * Can NOT be null
 */
public float $bar;

This type of syntax has a long-living predecessor - SQL (INT NULL). I think
it is readable and it does not introduce ambiguity as in string|null case:
one might suggest that "string|int|float|null" is also possible. In my
solution, it is clear: the property either has the NULL predicate or it
doesn't.

Cheers!

On Fri, Mar 18, 2016 at 12:49 PM Marco Pivetta  wrote:

> To answer my own question: the entire RFC is a no-go in its current state.
> On 18 March 2016 at 10:09, Marco Pivetta  wrote:
>
> > That said, I have a few quite common use-cases that arise and that are a
> > bit problematic, both because they are hacks and because they are
> actually
> > used in large projects.
> >
> > Specifically, I'm worried about two particular use-cases:
> >
> >  * unsetting properties
> >  * by-ref property assignment
> >
> > To clarify, un-setting properties allows us to hide properties
> completely,
> > loading them on a per-usage basis:
> >
> > class Foo {
> > public int $bar;
> > public function __construct() {
> > unset($this->bar); // is this operation legal? For BC compliance,
> > I'd expect that to be the case
> > }
> > public function __get(string $name)
> > {
> > initialize_properties_here($this); // external thing connecting
> to
> > db, loading files, yadda yadda
> > }
> > }
> >
> > var_dump((new Foo())->bar); // what happens here? can
> > `initialize_properties_here` actually assign a non-int to `$bar`? Will
> the
> > type safety still work?
> >
>
> See https://3v4l.org/bsHXH/rfc#tabs - unset() doesn't work, and that
> breaks
> some basic PHP semantics that are covered by phpt tests, but just for the
> case of typed properties.
>
>
> > The by-ref property assignment is a bit trickier, but can probably be
> > worked around with some overhead (re-assigning).
> > Here's what is going on:
> >
> > class Foo {
> > public int $bar;
> > public function __construct() {
> > unset($this->bar);
> > }
> > public function __get(string $name)
> > {
> > $this->bar = 123; // default value
> > $props = ['bar' => & $this->bar]; // is this operation now
> > considered illegal?
> > initialize_properties_here($props); // external thing connecting
> > to db, loading files, yadda yadda
> > }
> > }
> >
>
>
> See https://3v4l.org/sKqYb/rfc#tabs - by-ref assignment is forcefully
> disabled, and that breaks some more PHP semantics just for the case of
> typed properties.
>
> To sum it up, the RFC has one major problem: it focuses on the WHEN
> assignments happen, rather than just checking WHAT is assigned.
>
> I think the scope of the proposal needs to be reduced strictly to type
> checking.
> As it stands, this is too magic (and I do qu
>
> Cheers,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
-- 
Best regards,
Victor Bolshov

Re: [PHP-DEV] Line profiler for PHP

[Crocodile]

Hello Jacob

Take a look at http://pinba.org/ . While this is probably not exactly (or
may be even not at all) the thing you asked for, it is definitely
interesting. It allows for some profiling *right on production. *There are
certain things that you only experience under heavy load, and this tool may
let you know what's happening.

Cheers,
Victor


2014-12-24 14:16 GMT+03:00 Derick Rethans der...@php.net:

 On Tue, 23 Dec 2014, Stanislav Malyshev wrote:

   The questions I have are: - Is this even possible?
 
  Yes, should be possible but:
  1. If you want precision, it would slow down your code a lot, as
  basically you need to record timing of each opcode, which can be very
  expensive.
  2. If you're ok with less precision, you can do sampling, but in that
  case you probably need your script to spend a lot of time in the same
  areas of the code to have any meaningful results, otherwise it'd be just
  random.
 
   - Are there any projects out there or being worked on that achieve
   this?
 
  Most of the profilers afaik go by functions. Most probably because
  line-level profiling would be so intrusive as to not produce really
  valid results, but maybe it can be done in a way that is not that
  intrusive.

 I have played with it for Xdebug, but it was too much of a slow down to
 be of any use...

 cheers,
 Derick

 --
 http://derickrethans.nl | http://xdebug.org
 Like Xdebug? Consider a donation: http://xdebug.org/donate.php
 twitter: @derickr and @xdebug
 Posted with an email client that doesn't mangle email: alpine


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

Re: [PHP-DEV] Ruby's symbols

[Crocodile]

Sounds like it could make some sense. However, I've got a question..

array(
 'label' = 'Comment',
 'required' = false,
 'property_path' = 'properties.comment'
)

is actually equivalent to

array(
 'label' = 'Comment',
 'property_path' = 'properties.comment',
 'required' = false,
)

(Notice the change in keys order. As long as we just use those arrays as
hash maps, we notice no differences).

With symbols, which act as aliases for integer array keys, the situation
could be different, right? Or excuse me if I don't get what symbols are (I
don't know much about Ruby)

Cheers,
Victor

2013/1/5 Nikita Nefedov inefe...@gmail.com

 array(
 'label' = 'Comment',
 'required' = false,
 'property_path' = 'properties.comment'
 )

Re: [PHP-DEV] Re: RFC: source files without opening tag

[Crocodile]

IDE creators will definitely be excited with this new feature.

2012/4/9 Tom Boutell t...@punkave.com

 On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer vch...@developersdesk.com
 wrote:
 
  Option 1: Introduce require_path
 
  I think require_code is a better name.  Parm 1 isn't a path, it is a
 file,
  so require_path seems wrong to me.

 Yeah, you're not the first to say this. require_file and require_code
 have both been suggested. I'm fine with either really.

  I'd prefer a 'start in code mode' optional second parameter to
  include[_once] and require[_once].

 That would be fine as far as my goals here go, but I'm concerned that
 we'll just repeat this discussion if any other options for requiring
 things come into being (:

  Option 2: Filename Convention
 
  The PHP engine should not know or care what the file extension is.  I
 won't
  object if you can convince autoloader authors to follow the .phpc
  convention.  Personally, once I can count on this feature, every file I
  include/require will probably be written starting in code mode and using
 the
  new calling convention.  Even when I use PHP to create page templates...

 Sounds like you're basically OK with that bit.

  Additional suggestions:
 
  Add an option so the CLI can start in code mode too.
 
  Add another Handler to the Apache SAPI, maybe
 application/x-httpd-php-code
  similar to x-httpd-php and x-httpd-php-source, so we can configure
 Apache to
  start arbitrary file extensions with code mode on.  This defers setting
 the
  action for various file extensions to the person configuring the web
 server.
 
  Other web server SAPIs will need similar treatment, but I'll leave them
 to
  someone with personal experience.

 I'm not opposed to these suggestions. I was trying to keep it
 conservative and simple to implement and focus on the case where it
 bugs me (creating libraries of class files), but I'd be happy to see a
 way for .phpc to be the entry point / frontend controller / standalone
 script as well. As you say it must be done with SAPI options (the CLI
 included), not hardcoded file extension checking.

 --
 Tom Boutell
 P'unk Avenue
 215 755 1330
 punkave.com
 window.punkave.com

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

Re: [PHP-DEV] Object oriented page templates in PHP

[Crocodile]

@ before a function call will simply turn off error reporting for that
particular call. You will have to choose a different syntax. And, yes,
personally, I am against this suggestion. There are template engines that
already do similar things (Blitz, for instance) without requiring changes
in the language core.

2012/4/9 Tom Boutell t...@punkave.com

 ?@addLinks($this-escape($foo)) ?

Re: [PHP-DEV] PHP class files without ?php at the top

[Crocodile]

Hello, Tom...

Are you seriously that bothered with '?php' at the top of your classes?
Are you serious when talking changing reguire/include behaviour just to
satisfy your wish?

To be also serious, I would mention the possibility of including URLs.
There is no such thing as file name extension in URLs. Thus your idea
should be forgot. Personally, I really think 1st of April is like
continuing in the internals mailing list...

2012/4/7 Tom Boutell t...@punkave.com

 Now that the flamewar has died down a little I'd like to try to have a
 civil discussion about this idea - *without* my admittedly
 inflammatory suggestion to kill ?php altogether.

 So here is what I am seriously suggesting:

 * The default behavior doesn't change. The parser starts out in HTML mode.

 * If the CLI sees a .phpc file extension, the parser starts out in PHP
 mode (no opening ?php is required). It is still possible to shift
 into HTML mode after that with ?.

 * If a require/include statement sees a .phpc file extension, the
 parser starts out in PHP mode.

 * If mod_php and FPM are able to see the path (I'm honestly not sure
 if they can or not), they look for .phpc as their indication to start
 out in PHP mode. If that's not possible then new options are defined
 to allow Apache to be configured to tell mod_php and/or FPM to do the
 right thing based on mime types etc.

 This way .php continues to behave exactly as it does today, and can
 interoperate smoothly with code that uses .phpc. .phpc can require
 .php and vice versa. They are friends.

 Thoughts?

 --
 Tom Boutell
 P'unk Avenue
 215 755 1330
 punkave.com
 window.punkave.com

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