On Sun, Jan 5, 2020 at 7:48 PM Rowan Tommins
wrote:
> On 05/01/2020 18:03, tyson andre wrote:
> >> Yes, I'm saying that the autoloader should be called for each lookup, so
> >> autoloading of Foo\strlen should come between checking if Foo\strlen is
> >> defined, and checking if \strlen is defined
On Fri, Jan 3, 2020 at 10:35 AM Nikita Popov wrote:
> On Fri, Jan 3, 2020 at 2:51 AM tyson andre
> wrote:
>
> > After a quick search, it turns out I've mostly reinvented
> > https://wiki.php.net/rfc/autofunc which I hadn't remembered.
> > The `spl_autoload_*()` changes it mentions is what I had
I'd like to address the examples - and why I think they don't demonstrate
that this feature is really useful in practice.
There are several examples similar to this one:
class Car
{
public int $yearOfProduction;
public string $vin;
}
This is either lacking a constructor to initialize the pro
On Thu, Jul 25, 2019 at 3:34 PM Nikita Popov wrote:
...
> Based on the received feedback, I plan to change this proposal from being
> "namespace-scoped" to being "directory-scoped" instead
...
I think that's a better approach.
But please consider doing this without adding another global funct
On Thu, Jul 18, 2019 at 4:28 PM Dan Ackroyd wrote:
> On Thu, 18 Jul 2019 at 11:08, Rasmus Schultz wrote:
> >
> > What about ...
>
> Although there might be real problems for this, please can you
> describe a concrete problem that will occur, in a library people us
On Tue, Jul 16, 2019 at 2:34 PM Bishop Bettini wrote:
> On Tue, Jul 16, 2019 at 3:51 AM Nikita Popov wrote:
>
> > On Tue, Jul 16, 2019 at 3:40 AM Arnold Daniels <
> > arnold.adaniels...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > PHP replaces dots with underscores for $_GET, $_POST and $_COO
For the record, we're a mid-size organization, building a modern product on
PHP 7 with a PSR-based stack.
We've shunned template engines and rely heavily on short open tags and
alternative control-structures - mainly because we insist on static
analysis and IDE support, which we get by manually ty
Hello internals,
How hard would be to add an unload (or reload) feature for
classes/interfaces?
I'm wondering with regards to running PHP as a deamon (with Swoole or
ReactPHP, etc.) could it be made possible to hot-reload e.g. for
controllers and view-models?
Of course, the other option is to la
> 1.3-1.5 times speed-up
Dare I ask.
But is this even worth while?
This does not bring PHP to the level of performance where you could
reasonably implement, say, interpolated image resampling or a JPEG
decoder/encoder, correct?
This is still orders of magnitude slower than C, am I wrong?
Pleas
ompatible with existing
string type-hints for class-names. (?)
On Wed, Feb 13, 2019 at 9:16 AM Joe Watkins wrote:
> What you describe is first class support for classes, nothing much to do
> with anonymous classes.
>
> On Wed, 13 Feb 2019, 09:01 Rasmus Schultz
>> The fact
The fact that the anonymous class syntax defines a class *and* immediately
constructs an instance is quite annoying.
For one, this is quite incompatible with DI containers' ability to resolve
constructor arguments.
Lets say you DI container can register a named component by merely
referencing a c
Regarding the mixed type-hint RFC:
https://wiki.php.net/rfc/mixed-typehint
> When no native type is present, it is unclear what type is expected
Regarding variance - in the examples shown in the RFC, it is still unclear
whether your intention was variance, or if you just omitted the type-hint
by
We've noticed something odd about the "php://input" stream.
This type of stream resource reports itself as seekable:
assert(stream_get_meta_data(fopen("php://input", "r"))["seekable"] ===
true);
https://3v4l.org/EFLiO
If you attempt to rewind() it after reading the stream, rewind() returns
true
On Tue, Oct 2, 2018 at 11:37 PM Rowan Collins wrote:
> While I can understand the desire to have debugging feature built into
> the language "out of the box", it may be best left to extensions which
> can capture the information to a log or wherever without providing the
> full flexibility of the
I understand the $errcontext argument to the set_error_level()
callback was deprecated in 7.2.
Apparently, this was deemed "not useful", but what's the alternative?
I understand that debug_backtrace() reports the arguments on the
call-stack, but... just the arguments - no local vars.
I understan
On Mon, Sep 24, 2018 at 11:24 PM Andrew Gromov wrote:
> > Bring a little Javascript into PHP?
>
> In fact, I looked at Kotlin :)
Kotlin does not modify classes.
This sort of thing is sound in compiled languages like Kotlin and C#, where
this is really syntactic sugar for calling user-defined fu
27;t already do, which is to guarantee that the type enforces it's own
state specification.
I understood the analogy, and I don't agree.
On Sun, Sep 23, 2018, 00:42 Rowan Collins wrote:
> On 22 September 2018 20:32:04 BST, Rasmus Schultz
> wrote:
> >if you read my last post (
x27;t want a particular
> engine
> pseudo-type (uninitialized); I honestly don't care about that level of
> implementation detail. I am only trying to offer suggestions for how to
> tighten the guarantees further without violating the basic facts of how
> PHP
> works.
&
I apologize for the long posts, but Larry asked me to comment on this.
On Thu, Sep 20, 2018 at 5:52 PM Larry Garfield wrote:
> I think the distinction here is that one group is arguing for "state of the
> data assertions" while the RFC as implemented is "setter assertion shorthand".
The point o
On Fri, Sep 21, 2018 at 10:24 AM Lester Caine wrote:
> Ignoring the debate on uninitialized/null ... not all objects ARE
> invariant
hence nullable types.
> and there are very good reasons for not setting values for
> everything, but it seems that these types of object are deemed to be
> 'bad c
On Thu, Sep 20, 2018 at 4:50 PM Levi Morrison wrote:
>
> This will be my last reply to this thread. Fundamentally:
>
> class User {
> public ?int $id;
> public ?string $preferred_name;
> public ?string $username;
> }
>
> ^ This permits null properties at all times. This is acceptab
On Wed, Sep 19, 2018 at 10:04 PM Levi Morrison wrote:
> I think this code should be allowed:
>
>class User {
> public int $id;
> public string $preferred_name;
> public string $username;
> }
This code is broken - by making the properties non-nullable, you're
liter
On Wed, Sep 19, 2018 at 7:43 PM Rowan Collins wrote:
> I agree that this is a hard problem, but I don't agree that this decision
> is being made "for now". If we allow "non-nullable but uninitialized"
> properties now, it will be extremely hard to change their behaviour in
> future.
I'm with Row
Nikita,
I think we'll need the mixed type-hint in any case if we're to move
ahead with generics?
On Sat, Jun 30, 2018 at 10:30 PM, Nikita Popov wrote:
> On Sat, Jun 30, 2018 at 10:17 PM, Sara Golemon wrote:
>
>> On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev
>> wrote:
>> >> Together wit
On Tue, Jun 5, 2018 at 9:22 AM, Rudolph Gottesheim wrote:
> ...
> Has there ever been a discussion about adding some of those features
> syntactically, but ignoring them during runtime?
That's what Hack does, and one of the main reasons we dropped Hack in
favor of PHP.
PHP is a reflective langua
> > Yes, this is an expected result under the flexible heredoc RFC. To avoid
> > issues, please use a heredoc label that does not occur within the string.
>
> Hmkay, so code that worked fine with PHP 7.1 and PHP 7.2 breaks with PHP
> 7.3. This breaking change should at least be prominently document
I've used Swoole, and it is in deed a very high quality extension - both in
terms of performance and stability.
I haven't used the low-level co-routines, but the HTTP server was rock
steady, no memory leaks, easy to implement and CRAZY fast :-)
Kind of turns PHP into a better version of Node tbh
- Using Fiber::resume() to initialize the fiber and resume feels
>>> awkward. Separate methods again would be better here, perhaps
>>> Fiber::init(...$args) and Fiber::resume($send).
>>>
>>> All Fiber created with a suspended status. So make resume to do both the
>>> init and resume
>>> do ma
Yeah, I keep thinking about this.
I'm not sure there's a really good reason why PHP shouldn't come with
best-in-class image support, if it's available - which it sounds like it
is; libvips looks more modern, lower memory and CPU overhead, better
overall really, and appears to be stable and up-to-d
ption on a standard PHP install) so that libraries
like Intervention Image can deliver predictable results.
I'm not a C developer though, so I can't help with that.
On Thu, Aug 17, 2017 at 7:03 AM, Pierre Joye wrote:
> hi Rasmus,
>
> On Tue, Aug 15, 2017 at 5:52 PM, Rasmus Sch
The following GD issue is all-too common:
https://stackoverflow.com/questions/5773032/how-to-stop-gd2-from-washing-away-the-colors-upon-resizing-images
Basically anyone who's ever accepted uploaded images and resized or
converted them, has bumped into this.
Only Imagick makes it possible to work
Back in 2014 there was an informal proposal on the mailing list to replace
PHP serialization with an efficient binary (msgpack) format.
https://www.mail-archive.com/internals@lists.php.net/msg69870.html
As argued back then, breaking serialize() and unserialize() is unacceptable
for many reasons.
ases, as merely inconsistency and a symptom of missing
design. I admire languages with little, consistent syntax and
widely-applicable, highly-generalized features.
I understand if not everyone shares my point of view.
On Wed, Jun 21, 2017 at 11:19 PM, Rowan Collins
wrote:
> On 21/06/2017 15:
n 21, 2017 at 5:19 PM, Stephen Reay wrote:
>
> > On 21 Jun 2017, at 21:04, Rasmus Schultz wrote:
> >
> > Once people see the nicer, shorter syntax,
>
> For anything but the most basic of closures, the shorter syntax just makes
> it harder to visually identify the logic.
;re saying these are an entirely new type of object that isn't an
instance of Closure, in which case I'd say this whole feature is guaranteed
to do considerably more harm than good?
On Tue, Jun 20, 2017 at 7:52 PM, Rowan Collins
wrote:
> On 19 June 2017 21:22:53 BST, Rasmus Schultz
> I just think your example is an exaggeration to what happens in practice.
I think it's an example of what happens with any inconsistent feature in
any language.
On Tue, Jun 20, 2017 at 9:53 AM, Markus Fischer wrote:
> Hello Rasmus,
>
> On 19.06.17 22:22, Rasmus Schultz wrot
oing, it's worth doing it right.
On Mon, Jun 19, 2017 at 10:12 PM, Larry Garfield
wrote:
>
>
> On 06/19/2017 03:45 PM, Rasmus Schultz wrote:
>
>> Or maybe it'll look okay if you format the code?
>>
>> $things->forEach({$v => {
>> foo(
Or maybe it'll look okay if you format the code?
$things->forEach({$v => {
foo($v);
bar($v);
}});
Still looks kinda crazy with the closing "}})" though...
On Mon, Jun 19, 2017 at 9:43 PM, Rasmus Schultz wrote:
> I actually like this syntax, but
I actually like this syntax, but what would it look like for
multi-statement closures?
A nested set of curly braces around the body would look pretty messy.
$things->forEach({$v => { foo($v); bar($v); }});
On Mon, Jun 19, 2017 at 4:43 PM, Levi Morrison wrote:
> On Sun, Jun 18, 2017 at 1:4
solves the ambiguity problem - it looks
> > exactly like a function call.
>
>
> Right. But it does solve the ambiguity if `fn` is a keyword which is what
> the RFC suggests.
>
>
> > On 18 Jun 2017, at 18:40, Rasmus Schultz wrote:
> >
> > I don'
I don't agree that the fn keyword solves the ambiguity problem - it looks
exactly like a function call.
As for the backslash, my honest reaction is, ugh, please, no more
backslashes - PHP (and every other language) uses backslashes for escaping
in strings, it already looks pretty awkward in namesp
sed in these contexts?
On Thu, Jun 8, 2017 at 5:56 PM, Fleshgrinder wrote:
> On 6/7/2017 9:45 PM, Rasmus Schultz wrote:
> >> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable
> > compromise.
> >
> > I have to second that.
> >
> >
> You are looking for the \G anchor or the A modifier.
Both of these options work great!
I've submitted a patch to the manual page with a note explaining these
options.
Thanks :-)
On Wed, Jun 7, 2017 at 10:13 PM, Nikita Popov wrote:
> On Wed, Jun 7, 2017 at 10:03 PM, Rasmus Schul
What do you think about adding another option to preg_match() to allow the
$offset parameter to be treated as the start anchor?
The manual proposes to do this:
$subject = "abcdef";
$pattern = '/^def/';
$offset = 3;
preg_match($pattern, substr($subject, $offset), $matches);
In oth
> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable
compromise.
I have to second that.
I might even propose to shorten it from "fn" to just "f" - the resulting
syntax then resembles a mathematical predicate :-)
On Wed, Jun 7, 2017 at 5:20 PM, Stephen Reay
wrote:
>
> > On
Ugh, you're right, that's totally unreadable... the => is far too ambiguous
with array syntax, I agree.
How about just a thin arrow?
(params) -> expr
If the parens around params were required, it's not ambiguous with the
trailing -- operator, is it?
$foo->bar(($baz) -> $baz + 1);
Consi
Of the proposed options, I'd prefer the double fat-arrow ==>
However, I remain of the opinion that all of those syntaxes are
work-arounds to ambiguity concerns for cases that likely don't actually
occur in real-world codebases.
I don't understand the motivation to design or optimize based on some
mit to
maintain!) both major and minor versions, which doesn't sound easy at all.
On May 29, 2017 00:53, "Dan Ackroyd" wrote:
> On 28 May 2017 at 14:25, Rasmus Schultz wrote:
> >
> > To me, that's a setback that leads to harder-to-debug errors, and
> inc
2017 at 2:27 PM, Niklas Keller wrote:
> 2017-05-28 12:30 GMT+02:00 Rasmus Schultz :
>
>> > > So this breaks the expected behavior of interfaces.
>> >
>> > No it doesn't. It allows interfaces to use contravariance within PHP's
>> > type sys
he desired behavior; it doesn't indicate anything, and
thereby creates a new problem case of accidental type-hint omission.
Is there a very good reason we shouldn't address that, if it's at all
possible?
On Thu, May 25, 2017 at 12:32 PM, Dan Ackroyd
wrote:
> On 25 May 20
> > The feature, as implemented, will allow accidental omission of
type-hints,
> > will it not?
>
> Yes, correct.
So this breaks the expected behavior of interfaces.
This will be harmful to everyone, but especially harmful to new
programmers, who may never even learn how to correctly implement an
This parameter type widening RFC, I didn't know about, but I have a remark.
The feature, as implemented, will allow accidental omission of type-hints,
will it not?
Previously, the implements keyword guaranteed a correctly type-hinted
implementation - it's now possible to (purposefully, obviously,
; Although DbC is not what you need, but DbC could solve your issue
> more efficiently. i.e. Faster execution, not shorter code.
>
> https://wiki.php.net/rfc/dbc2
>
> With DbC, caller has responsibility to pass correct parameters.
>
> On Sun, Apr 9, 2017 at 6:30 PM, Rasmu
r, right?
On Sun, Apr 9, 2017 at 1:07 PM, Rowan Collins
wrote:
> On 9 April 2017 10:30:02 BST, Rasmus Schultz wrote:
> >Example:
> >
> >class Foo { public function __toString() { return "foo"; } }
> >function append_to(string &$str) { $str .= "
Since PHP 7.0, I've started using scalar type-hints a lot, and it got me
thinking about scalar type-casting.
After poking through existing RFC's, it turns out, I was going to propose
precisely the thing that Anthony Ferrara proposed in 2012:
https://wiki.php.net/rfc/object_cast_to_types
In the l
10 thumbs up ;-)
But this really demonstrates how badly we need this function - I bet any
number of those points may or may not be covered by any number of
implementations in the wild.
It would be so nice to have this done "right", once and for all.
On Sat, Apr 1, 2017 at 2:42 PM, Fleshgrinder
r-case) drive-letter on Windows
There's also network file-system paths on Windows with a different syntax
to consider? I don't know much about that...
On Fri, Mar 31, 2017 at 11:40 AM, Pierre Joye wrote:
> On Fri, Mar 31, 2017 at 3:32 PM, Rasmus Schultz
> wrote:
> > Well,
tion of
> > "\\host\share/path/to/file" <--- wat?
> >
> > Overall, it smells of magic.
> >
> > -Sara
> >
> > On Thu, Mar 30, 2017 at 8:25 AM, Rasmus Schultz
> wrote:
> > > Today, I ran into a very hard-to-debug problem, in which paths (to
Today, I ran into a very hard-to-debug problem, in which paths (to SQL
files, in a database migration script) were kept in a map, persisted to a
JSON file, and this file was moved from a Windows to a Linux file-system -
because the paths on the Linux system had forward slashes, the files
appeared t
ary search...
On Fri, Mar 3, 2017 at 10:28 PM, Nikita Popov wrote:
> On Wed, Mar 1, 2017 at 4:35 PM, Rasmus Schultz wrote:
>
>> Hey internals,
>>
>> I was wondering whether or how PCRE regular expression get parsed and
>> cached, and I found this answer on Stack Ove
FWIW, these constants are not universal.
In Postgres (and MySQL since 5.7) the date+time types have optional
sub-second precision - which the "Y-m-d H:i:s" pattern will fail to parse.
Another common case in Postgres is date+time with timezone, e.g. used for
scheduling/calendar applications etc. -
d/or
missing an opportunity to cache between requests in long-running apps or
under FPM.
I think most apps use quite a lot of regular expression for validation etc.
so maybe there's a missed optimization opportunity here?
Cheers,
Rasmus Schultz
In the light of this, maybe enums (assuming this feature comes first)
should be implemented as immutable objects rather than values?
Type-checking for enums would be important, so in PHP terms, an enum
"instance" would likely be closer to an object than a value in nature
anyway.
The way I look at
Just my two cents, but moving and aliasing core PHP
classes/interfaces/functions sounds like an absolutely horrible idea.
My biggest question is WHY would you do that?
Writing user-space code today that uses the global namespace would be
considered extremely bad practice - no one should do that.
I'd strongly prefer a syntax without the introduction of "fn" keyword -
e.g. similar to closures in other languages.
I also feel that there's a feature missing - something that was possible
with closures:
$total = 0;
$add = function ($value) use (&$total) {
$total += $value;
};
Per the RFC:
We were talking about this exact issue at work today.
Supporting this for interfaces would be particularly useful - if an
implementation better than satisfies the requirements defined by an
interface, it should be able to implement that interface.
I'd be very happy to see an RFC for this :-)
On
> Basically Foo[] to indicate an array of objects of type Foo
I would be fine with that, as long as it's sugar for array
On Sun, Jan 29, 2017 at 4:51 PM, Sebastian Bergmann
wrote:
> Am 28.01.2017 um 17:10 schrieb Niklas Keller:
> > sounds like everything you want is typed arrays?
>
> I would l
> The Collection is Iterable, Traversable, Countable like an array to be
> compatible with foreach and other Traversable-compatibles functions.
Right, so it's an array.
Except, it's an object-type, rather than a value-type like arrays. (I'm
guessing - I don't think you specified?)
And it's type-
> old applications could maintain compatibility only
> by adding a simple autoloader that would alias the global
function/constant
> into the calling namespace
So as a side-effect of calling any function, my namespace would get
polluted with all sorts of random names? That sounds like a messy
work
wrote:
> As a userland developer I feel $$ (or some variation starting with $) is
> reasonably natural - it's a variation on a regular variable.
>
>
>
> Sent from my iPhone
>
> > On 25 Jan 2017, at 03:53, Levi Morrison wrote:
> >
> >> On Tue, Jan 24,
> if you choose to use static methods instead of functions
It's not a choice - functions are practically useless in a Composer
context, and most everything PHP is now Composer packages.
> why do you need this special syntax for calling them then?
Yeah, but the same logic applies to namespaces an
ges) are currently implemented as public static functions,
and in my opinion, this is starting to sound less like a stop-gap and more
like a simple solution to a problem we've been solving with a stop-gap for,
oh, 10 years or so...
On Jan 26, 2017 10:05 AM, "Andrea Faulds" wrote
Isn't `_` more generally used as a "discard" placeholder in most languages?
At least in Swift, Go, Scala, Dart and C# (starting with v7) I think?
I don't recall having seen it mean "fill in the blank". In what languages?
On Fri, Jan 20, 2017 at 4:26 PM, Levi Morrison wrote:
> Oops, sorry for
> How hard is it to write Foo::bar? You never have to go more
than one level. I don't see a point in mixing internal function
namespace with class methods for the sake of saving typing couple of
characters.
I'm not suggesting we mix namespaces - this of course would be file-local,
same as use-stat
Just a quick thought.
Since the autoloading functions proposal is stalled, how about allowing for
import of static functions instead?
use function Foo::bar;
bar(); // calls Foo::bar()
There are two benefits to this approach:
1. There is immediate support for autoloading without any nee
On regular PHP 7, the array weirdness (Dmitry's last example) doesn't even
produce a warning:
class Shit {
public $yo = false;
}
$shit = new Shit();
$shit->yo[] = "what"; // quitly turns $yo into an array!
echo gettype($shit->yo); // array
That's pretty messed-up right there. At least in t
But this leads to code that can't pass static inspections?
interface Joiner {
public function join(array $array): string;
}
class WideJoiner implements Joiner {
public function join($iterable): string {
$array = is_array($iterable) ? $array :
iterable_to_array($iterable);
Reading through the RFC and the replies, I'm confused about this question.
Why would the comparison operators work any differently on immutable
objects?
If these were value objects, the question would make sense, but it doesn't
sound like that's what you're proposing?
With regards to the feature
> if you've hired developers that care more about trends than your
application then you've hired the wrong developers.
A consistent, complete type-system is not a "trend".
In my experience, good developers notice things like inconsistency - and
they generally do not like it.
I am personally *not
Heh, so, this week, a coworker of mine started using PHP 7, and he calls me
over, and he's like, "I don't get it, I had heard PHP 7 was supposed to
have type-hints now - it worked for return-types, but what am I doing
wrong, I can't seem to get this to work for properties?"
He actually had somethi
also the names
should probably be array_first() and array_last() for consistency with
other array-only functions.
Perhaps better to make people be explicit, rather than trying to hide
side-effects to achieve shorter syntax...
On Sun, Oct 30, 2016 at 2:14 PM, Fleshgrinder wrote:
> On
ast()`.
> Continuing with the `array_` prefix makes perfect sense to me, even if
> they accept `\Traversable` instances as well. We also expect `str_`
> prefixed functions to accept stringable objects, dont' we. It's just a
> prefix for grouping and not necessarily a restrictio
:45 PM, Nikita Popov wrote:
>> On Sun, Oct 30, 2016 at 12:24 PM, Rasmus Schultz wrote:
>>
>>> With regards to deprecating array-functions that operate on the
>>> internal pointer - I'd like to just remind you of the fact that some
>>> of these functions, re
With regards to deprecating array-functions that operate on the
internal pointer - I'd like to just remind you of the fact that some
of these functions, reset() and end() in particular, are often used
not because someone cares about moving the internal pointer, but as a
means of getting the first/l
On Wed, Aug 10, 2016 at 4:08 PM, Christoph M. Becker wrote:
> Sounds reasonable, Anotol. Thanks. So I'm going to update 7.1+ ASAP.
Are you going to include any plugins?
I noticed today, SQLite has interesting optional features - in
particular, the "json1" plug-in looks interesting.
Both MySQ
On Tue, Aug 9, 2016 at 6:17 PM, Rowan Collins wrote:
>> In other words, calls to substr() does not trigger the resolve - a
>> statement like "use function substr" on the other hand, does.
>
> Ah, I see. The problem with that is, you still have to explicitly list every
> function you're going to u
On Tue, Aug 9, 2016 at 12:04 AM, Rowan Collins wrote:
> I don't quite follow what you're suggesting here. When does this "function
> resolver" get called?
I'm suggesting the use-statement be the trigger, rather than actually
calling the function.
In other words, calls to substr() does not trigg
On Mon, Aug 8, 2016 at 10:54 PM, Lester Caine wrote:
> I can understand a little the overwhelming desire to wrap everything in
> it's own set of name spaces, but is that REALLY essential to make PHP
> 'work better'. What is wrong with a simple 'include_once' of the library
> you want to use global
ment, and would make them
effectively "autoload" - I imagine it's no more costly to pre-register the
protocol/class-name than e.g. pre-registering some other form of
auto-loader?
On Mon, Aug 8, 2016 at 10:23 PM, Davey Shafik wrote:
> On Mon, Aug 8, 2016 at 1:15 PM, Rasmus Schultz
ectHashOn.php
>
> > return compare_on($comparison, $keyFunction);
>
> Although interestingly, at the top of the file there is a (technically
> unnecessary) "use function Functional\compose;" If there was a "use
> function Functional\compare_on;" a
> If not, I don't see why we ever need to be able to autoload global
functions
Well, for consistency.
For one, if you're refactoring a global function to a namespaced one, this
inconsistency is going to be surprising.
In general, any inconsistency in a language is surprising. Why only
non-global
ers who choose a high-level scripting
language, and we will lose.
On Sun, Aug 7, 2016 at 1:29 PM, Nikita Popov wrote:
> On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz wrote:
>
>> I'd really like to see the function auto-loading proposal revived and/or
>> possibly simplifi
I'd really like to see the function auto-loading proposal revived and/or
possibly simplified.
The fact that functions are hard (in some cases impossible) to reach by
manually issuing require/include statements is, in my opinion, half the
difficulty, and a much more deeply rooted language problem e
Looks like it's unanimously a No.
Michael, don't be discouraged - I think that everyone agrees that there is
a problem to be solved, it's just that no one except you thinks this is a
good solution; many of us are of the opinion that it's not a solution that
really addresses the problem at all: you
> the problem IS NOT that we don't have a solution
> The problem IS that developer
> must call these functions everywhere manually.
What you don't seem to get, is your proposal doesn't change that fact?
It changes the syntax and means by which you select and call the function,
but it still re
I agree, an argument that essentially turns it into a different function is
not a good practice.
Suggestions for a function-name?
typeof() or vartype() maybe?
On Fri, Jul 29, 2016 at 8:17 PM, Niklas Keller wrote:
> >
> > Niklas Keller wrote:
> > > I'm not sure on the boolean through, I think
Just a thought, but I can't help thinking that "improved escape facilities
and syntax" are a mere patch for a more than superficial problem.
The problem of differentiating HTML strings, which to not require escaping,
from other string, which do, could actually be viewed as a deeper problem,
which
FWIW, I've read the manual page for the Hack page, and the RFC, a couple of
times now, and I simply don't understand it.
Are most PHP developers going to understand this feature, the meaning of
$$, and when/how to use this?
Are they going to be able to read code written in this way?
To your know
This is a really good point, Marco.
Of course, this would be much cleaner with a set of functions, since $this
(whatever it is) is not truly a dependency for any of these functions -
they're likely sharing no context or state; they've likely been placed in
the class solely to make them available t
> Registry of functions - is exactly how escaping is performed in Symfony
and Twig.
For one, that does not mean it's a good idea.
For another, the registry in Symfony (at least, I don't know about Twig) is
inside an instance - it's not global state.
Do you get my point that a reference to a clos
1 - 100 of 272 matches
Mail list logo
