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
g 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 t
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!
> &g
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. 20
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 S
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
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
do
ter 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 choos
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ć
> wrot
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 s
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 wrote:
>
> Am 02.03.17 um 16:46 schrieb Crocodile:
> > While I agree with everything
tually 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 wrote:
> Hi Victor.
>
>
> Am 02.03.17 um 15:48 schrieb Crocodile:
> > H
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";
co
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 sup
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
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
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 t
Stopped reading after encountered "E_ACTUALLY_ALL", "for ($foo as &$bar)" -
these things required me to google or to refer to docs to ensure I was not
missing something. And, yes, I should have stopped after the words "don’t
tell me anything!". People who refuse to listen do not deserve to be heard
@ 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 la
IDE creators will definitely be excited with this new feature.
2012/4/9 Tom Boutell
> On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer
> 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 wron
Hello, Tom...
Are you seriously that bothered with '
> 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
> So here is what I am seriously suggesting:
>
> * The default behavior doe
22 matches
Mail list logo
