phpHeader header = CreateHeaderFrom(userobject);
char *result = PHPProc(file, filesize, header);
struct phpResultHeader headerback = PHPResultHeader();
Send_To_User(userobject, headerback, result);
free(result);
return;
}; // and call that from my file
Sara Golemon wrote:
>> Hello all, I hope this is the right place to write about this. I've been
>> trying now for quite some time to integrate php into my non-apache server
>> (completely c++ written by me).
>>
> Sounds like you want to use sapi/embed (or write a SAPI implementation of
> your own
Haha, after looking over the enviorment variables one last time I noticed it
was setting the content length to zero, my fault. After fixing this, it
seems to be working! Yay, yet another webserver with php support :)
www.sf.net/projects/ante
Matthew wrote:
> Sara Golemon wrote:
>
>
I'm sorry if this is the wrong place for this post, I just don't know where
else to go.
I need some help figuring out how to use FCGI_STDIN with a running php
script.
I have written a server in c++, which for a while been running php through
it's plain old cgi interface. I have been using php fo
ipting ever
convieved.
>
> -- Original message --
> From: "Wez Furlong" <[EMAIL PROTECTED]>
>
> > IMO, you're better off using stream_socket_server() and writing a
> > "real" daemon for that. Abusing fastcgi/cgi to work in that
using
multiple libraries and they are each overriding their (and your)
settings? It just feels messy.
The same thing could be accomplished config-less with a callback
system that is triggered on script includes (if any callback returns
false, an error is thrown), but I think I'd dislike that
PERDIR setting, then I wouldn't really mind as much.
But as PHP_INI_USER, I don't like it at all.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ed on.
Policy states that 2/3s means consensus on core language changes. The
current 63.5% isn't too far from that. Just curious, but do you have a
different number in mind for this vote? 90%? 80%?
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
fair IMO is to hold a vote where you rank those
four options (weak, strong, both, neither) and hold an instant run-off
vote where the first majority wins. And if 'neither' wins, then agree
that the topic cannot be revisited until next major version, so that
everybody can rest for 5 years. ;)
-
ed, maybe $foo would just be a
ReflectionClass object. (I haven't really thought that one through...)
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e clear, I'd actually be fine with a weak-only implementation that
follows the same exact rules as the explicit casts. And I'm okay with
strict-mode optionally tacked on top of that -- because it can be
useful and won't get in my way. But I'm no longer in favor of any
in-between co
able::fromInstance($dateTimeImmutable) could just return
the same object.)
So while not a pressing issue, I do think a more straightforward way
of converting would be good because the reality is that you're going
to need to do the conversions at some point if you interface with
other pe
work they have put into their proposals. So big
thanks to all of you!)
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
appeal to this.)
3) In rare cases, Gaming the system - closing the vote at the exact
time that benefits the owner of the RFC.
So I don't think there's anything sinister here. It's just the natural
result of the voting rules.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is
irrelevant. The type checking mode depends on the file where the
function is called."
If it were the other way around, then you'd be correct -- it would be
a disaster.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I don't think your suggestion explains the feature any better than
strict_types. (Although the irony of using =1 instead of =true isn't
lost on me!)
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On 13 Aug 2024, at 12:36, Gina P. Banyard wrote:
>
> On Tuesday, 30 July 2024 at 11:49, Gina P. Banyard wrote:
>
>> Hello Internals,
>>
>> I have just opened the vote for the "Transform exit() from a language
>> construct into a standard function" RFC:
>> https://wiki.php.net/rfc/exit-as
> On 13 Aug 2024, at 13:43, Gina P. Banyard wrote:
>
> On Tuesday, 13 August 2024 at 14:05, Matthew Sewell wrote:
>
>>> On 13 Aug 2024, at 12:36, Gina P. Banyard intern...@gpb.moe wrote:
>>>
>>> On Tuesday, 30 July 2024 at 11:49, Gina P. Banyard i
;>>
>>> Those I've spoken to in php.doc agree. Any objections?
>>>
>>> Thank you,
>>> Justin Martin
>>>
>>
>> I'm +1 on this. It's time for a new, more collaborative approach.
>
> Sure, I'll +1 on this. The "bogus" implies "RTFM, bitch", which isn't
> professional at all :-)
I've felt this way for a long time. Big +1 on changing this.
Cheers,
--Matthew
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
; On Sat, 2012-04-07 at 11:23 -0700, Matthew Hernandez wrote:
> > This is my first extension I'm working on. I'm trying to make a class
> > available to the user space with 1 private property that is an array.
>
> The first question is: Why? - Why add the overhead of cre
RE) {
RETURN_FALSE;
}
add_next_index_zval(foo_class_object_ptr->elements, item);
RETURN_TRUE;
}
However, this doesn't work. when you call FooClass::add it causes a
segfault. I'm sure I'm abusing something :)
thx
On Sat, Apr 7, 2012 at 2:38 PM, Matthew Hernandez wrote:
> Hi Johannes,
&g
g fault, I'm trying to understand why.
On Sat, Apr 7, 2012 at 8:41 PM, Xinchen Hui wrote:
> hi：
> You can refer to ext spl array
>
> Thanks
>
> Sent from my iPhone
>
> 在 2012-4-8，7:12，Matthew Hernandez 写道：
>
> > Here's what I have so far:
> >
> >
On Sun, Apr 8, 2012 at 2:26 AM, Derick Rethans wrote:
> On Sat, 7 Apr 2012, Matthew Hernandez wrote:
>
> > How can I valgrind my extension? Google isn't bringing up many php
> > extension topics :/
>
> On the shell:
>
> export USE_ZEND_ALLOC=0
> export ZEN
Option [a] seems like the most logical thing to do, would probably work the
best. It might be nice to note on php.net somewhere right now before this is
fixed that PEAR will not install.
The options we have, as far as I can tell, are:
[a] Re-release 5.0.4 with that file
[b] Release 5.0.5 with th
Work on SDO extension
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
> On Mon, 3 Oct 2005, Greg Beaver wrote:
>
>
>>> 1. zlib is required now with php, and by default php isn't installed
>>> with zlib nor does configure catch this, so, while make install is
>>> running and when pear is being installed make dies leaving a bad
>>> installat
Matthew Kavanagh wrote:
> Would that really be a problem, given that compressing a compressed file
> and compressing an uncompressed file will usually yield similar sized
> resultant files?
>
...and I failed to see the previous email that says the same thing.
Genius at work.
Where do these two belong on the build system for a Win32 build?
- bindlib_w32
- win32build
> PHP may be a hybrid language, but the fact is you're implementing object
> oriented functionality, and as such should be implementing it in a way that
> follows de-facto standards in object oriented language design. I should be
> able to overload your internal array object, and yes, arraysshould
sible classes, think about
> _-autoloading classes, which means we'd have to do more work during
> execution, which can be a slowdown.
>
> johannes
>
>
--
Matthew Schiros
President, InvisiHosting.com
Web Dev
Hi,
The arg info for array_map appears to be incorrect. It lists 3 arguments as
required, when in fact there are only 2 required. Attached is a small patch
to fix it.
Regards,
Matthew
Index: basic_functions.c
===
RCS file
Lester Caine wrote:
I'm sure many people have their own preferred tools for creating files
- all I was trying to say was that - is taint support actually needed
at run time? Something that improves the visibility of mistakes while
editing files seems to be more worthwhile - something that can a
l it is to optimize that away to nothing, but
it would be more consistent with regard to throwing exceptions and
would allow for a variety of different class methods.
--
Matthew Leverton
On Sun, Oct 20, 2013 at 8:52 PM, Joe Watkins wrote:
> On 10/20/2013 12:15 AM, Ferenc Kovacs wrote:
>>
On Wed, Aug 13, 2014 at 3:24 AM, Peter Cowburn
wrote:
>
> My thoughts on the topic? I think we're in danger of letting "process" get
> in our way here. It's a bug fix which IMHO should even be thrown into 5.6
> (this is a bug fix!). Going through the RFC process, being forced to wait
> for 5.7 or
) { } == f( (int) $a); -- with NO notices
2) function f(int $a) {} means $a must be exactly type int -- or
recoverable error is thrown
3) current behavior (no scalar type hints)
But a new set of rules that require a 23x7 table to describe what's
going on ... not a big fan.
--
Matthew Le
thin the
expressions. Either way, still +1 for this feature.
Best regards,
--Matthew
dx3', $_POST, 'myDefaultValue');
>
>
> Regards,
> Mathias
>
Hi Mathias,
The new null coalesce operator in PHP 7 achieves what you're looking for
here. See https://wiki.php.net/rfc/isset_ternary
Best regards,
--Matthew
s. Because I
wouldn't want to have two different styles of code depending on the
library I'm using, I'd end up again going back to assuming everything
was a strict type.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
types
is far preferred to nothing. There are good arguments on both sides
... let the voters decide.
After that, additional RFCs could be created to address raising errors
on auto case, using declares to toggle behavior, etc - depending of
course on what was decided on prior vote.
--
Matthew
ally works in practice? But a library with type-hints + a script
to prepend "use strict" to every PHP file would make testing impact on
real-world usage easy for anybody.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s. BC" rabbit hole
> here, but I'm just wondering what the general consensus is on this right
> now.
>
> http://php.net/manual/en/class.exception.php
>
>
> Thanks!
>
> --Kris
>
Hi Kris,
See http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS#137
Best regards,
--Matthew
. See
http://www.red-team-design.com/firefox-doesnt-allow-cross-domain-fonts-by-default
The attached patch unconditionally sets it for all static files.
Should I submit a bug report, or is this email sufficient to get
somebody to look at it?
--
Matthew Leverton
--
PHP Internals - PHP Runtime Develo
uction web server.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
th the powers-to-be doing whatever they feel appropriate.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ar)
I assume that function fn($a, $b = null, ...$c) is possible, and the
only way to populate $c is to call fn with three or more parameters.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
& current behavior),
CRC32_INT32 (always negative if high bit is set), CRC32_UINT32_STRING,
CRC32_HEX_STRING
Forgive the poor names.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
dismissive of your complaints (because
they are valid), I just don't see how two bandaids over specific
instances of a larger problem do much good. Although, to be pragmatic,
I offered what I feel is a better solution than your extra functions.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eters are set in stone before this feature would go live?
So I'm neutral to this proposal, as I would never purposefully build a
function that is so convoluted that it needs named parameters, but I
understand that's how some people like to write code, and it could be
useful in extreme case
On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue wrote:
> Matthew Leverton wrote:
> This is already the case. In libraries that accept options via an array,
> those array keys are pretty much set in stone (although you can map them
> if you need to change a key).
>
The big differen
=> 'override');
Now is 'c' overridden or 'd'?
So I'll give this issue a rest unless somebody wants to further
discuss what the concrete syntax might look like.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
h adds useless overhead.
There are a few keywords, such as list and unset, that I often wish I
could use in PHP. So in terms of readability, I think any sane
programmer would use this proposed functionality for good...
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> binary compatibility) as well extended with additional functionality (object
> hint, type casting, reflection support, etc...).
+1
Regards,
Matthew
>
> The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt
> The test suit is available
against PHP_5_3. I wasn't sure which branch I should write it
for--let me know if it should be against another branch. This is my first
patch submission so any comments are appreciated.
Regards,
--Matthew
Index: ext/standard/ar
hints meaning that it doesn't
present the controversies of strict vs. weak, so I think it could be a
good candidate for inclusion. I made a patch a few weeks back to do
this and can post it if anyone is interested.
Best regards,
--Matthew
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t;>
>
> I think it's a good idea.
>
> It won't spark interest in those that have already memorized the more
> compact hexadecimal representation of nibbles, but otherwise it's useful a
> simple non-BC breaking addition.
Agreed. I have often thought this would be u
phpdoc-en-trunk-patch.diff is against phpdoc/en/trunk
Any feedback and/or approval/merging would be appreciated.
Regards,
Matthew Turland
Index: ext/spl/tests/SplObjectStorage_removeUncommon_basic.phpt
===
--- ext/spl/tests
val/merging would be appreciated.
Regards,
Matthew Turland
Index: reference/spl/splobjectstorage/removeuncommon.xml
===
--- reference/spl/splobjectstorage/removeuncommon.xml (revision 0)
+++ reference/spl/splobjectstorage/removeunco
Sorry to flood the list, but I noticed that I left a stray reference
to removeCommon in my amended patch. Attached the fixed version. My
profound apologies.
Regards,
Matthew Turland
Index: ext/spl/tests/SplObjectStorage_removeUncommon_basic.phpt
ave negative
indices. Changing their behavior would be a major BC break.
Best Regards,
--Matthew
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky wrote:
So you propose to give a partially working tool that promises data
security and then expect people not to rely on it 100% because it is
easy to
Nobody at all in this discussion has suggested taint promises data
security. Nobody has said it promises anything. But an imper
Ilia Alshanetsky wrote:
To use your car analogy and safe_mode history, most users will start
driving like maniacs, violating every traffic law thinking that the
seat belt makes them invincible.
Most users drive like maniacs anyway, and it will ever be so. Taint mode
cannot save people from them
Rasmus Lerdorf wrote:
Stanislav Malyshev wrote:
Compile-time resolution means you don't get performance penalty for
namespaces when you are not using it, and have very low costs when you
do use it. Allowing blanket imports means we don't know what "new Foo()"
means until it is executed - mean
ced me that it wasn't just me seeing a valid use case for it,
and that others have implemented differing solutions when presented with
the same situation. Given that, I believe a simple, utility, function such
as this would be of help.
As for who would implement it, that would be me.
--
Thanks kindly for the rapid and very helpful feedback. I'm going over it
today and will collate it and think over it further. Given that the
feedback's been so constructive and positive, I'll be getting started on an
RFC over the next day or so.
Matt
--
Kind regards,
Hi,
This is a really interesting thread and am glad that Stephan raised it as I've
been thinking along similar lines for a while now and am glad I'm not the only
one.
Considering the range of people adding comments (especially someone like Mark)
then I would hope everyone agrees that this dese
What's meaningful in this sense?
I have a budget for supporting open source projects (back to my money v time
point) and a percentage of that is for the PHP Foundation. I'd happily pay LTS
fees we pay elsewhere (even sometimes as a safety net) to the Foundation but
believe that the money we giv
idea (I have a separate problem in that
our projects are rarely on GitHub or GitLab) but does anybody who would
actually benefit from it have any thoughts on whether it would be good for them
or not?
> On 11 Apr 2023, at 10:09, Matthew Sewell wrote:
>
> What's meaningful in this
> On 13 Apr 2023, at 09:29, Andreas Heigl wrote:
>
> Hey all
>
> On 12.04.23 22:44, Larry Garfield wrote:
>> On Wed, Apr 12, 2023, at 6:42 PM, Rowan Tommins wrote:
>>> Which brings me back to my earlier point: I wonder how much of the
>>> reaction is really about e-mail itself, and how much i
>
> Regarding $field vs. $this->propName, there's a few reasons we went that
> route.
Overall I think this is a really good proposal, but you might want to
consider a second vote for that particular syntax.
`$field` vs `$this->propName` feels a little magical. It's a simpler magic
than actual ma
> On 15 May 2023, at 19:51, Rowan Tommins wrote:
>
> On 15 May 2023 19:38:56 BST, Larry Garfield wrote:
>
>> I agree entirely. Setting reasonable expectations for users to plan around,
>> such as a known 5-years-per-major cycle, helps end users far more than
>> "whelp, we did something big
Hi,
I'm using Gmail too but with a custom domain. I did get those three
messages but significantly delayed from when they were on externals.
Best wishes,
Matt
On Sat, Feb 17, 2024 at 4:15 PM tag Knife wrote:
>
> On Fri, 16 Feb 2024 at 23:50, Jorg Sowa wrote:
>
>> Hello Derick,
>> there is so
>
> What's the advantage of a language construct over the following?
>
> ```php
> /**
> * @template T of object
> * @psalm-assert T $value
> * @param class-string $type
> */
> function as(mixed $value, string $type): mixed
> {
> if (! $value instanceof $type) { throw
> SomeKindOfException::
On Thu, 8 Aug 2019 at 19:08, Zeev Suraski wrote:
> 3. Putting your apparent personal bias against backwards compatibility
> aside - if P++ goes in the directions you're hoping for - towards giving
> you the goodies on your wish list, why would you care if PHP still existed
> without these new ch
There are already some userland taint-checking solutions for PHP e.g. the
Phan taint-check plugin from MediaWiki:
https://www.mediawiki.org/wiki/Phan-taint-check-plugin
I'm working on my own userland solution, too (based on Facebook's
approach). Demo is here: https://psalm.dev/r/ebb9522fea
> If anything, this proposal would help user-land solutions (it gives them
> more information while the code is in running).
>
Well, it might help runtime-based user-land solutions, but not static
analysis-based solutions.
In our bug disclosure program at Vimeo we've had no SQL injection issues
r
Looking at our notice logs, I estimate (fairly roughly) that it would
require about a week's worth of my time to fix these issues in vimeo.com’s
700K LOC codebase (the undefined variables are confined to our views).
IMO it's akin to taking the training wheels off the language – I think the
PHP eco
2019 15:22:22 BST, Matthew Brown
> wrote:
> >Looking at our notice logs, I estimate (fairly roughly) that it would
> >require about a week's worth of my time to fix these issues
>
> I honestly thought you were posting that as an argument against. A week of
> resource
ew code with sth like declare(strict_variables=1);
> or declare(SomeNamespace\Foo:strict_variables=1); That way, people can write
> new code in a better way, include new libraries and upgrade old code piece by
> piece without any big pressure.
>
> Regards
> Thomas
>
>>
It's not breaking all the things - it's breaking code that should have been
broken already, but somehow wasn't.
On Wed, 28 Aug 2019 at 12:38, Rowan Collins wrote:
> On 28 August 2019 16:05:13 BST, Marco Pivetta wrote:
> >A week for 700KLOC is *impressively low*.
> >Many organisations spend more
Wed, Aug 28, 2019 at 5:22 PM Matthew Brown
> wrote:
>
>> Looking at our notice logs, I estimate (fairly roughly) that it would
>> require about a week's worth of my time to fix these issues in vimeo.com
>> ’s
>> 700K LOC codebase (the undefined variables are conf
both static analysis
tools and runtime error handlers.
On Wed, 28 Aug 2019 at 13:24, Rowan Collins wrote:
> On 28 August 2019 17:53:55 BST, Matthew Brown
> wrote:
> >It's not breaking all the things - it's breaking code that should have
> >been broken already, but
I'm no management expert, but I'd be surprised if a boss who won't set
aside time to fix a few undefined variables nevertheless green-lights
rewriting everything in C#.
On Wed, 28 Aug 2019 at 12:26, Chase Peeler wrote:
> On Wed, Aug 28, 2019 at 12:12 PM Mark Randall wrote:
>
> > On 28/08/2019 1
e well to other languages.
With this change we can make it harder for people to write bad code, which
I think will result in existing PHP users becoming better developers.
On Wed, 28 Aug 2019 at 14:32, Zeev Suraski wrote:
>
>
> On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown
> wrote:
>
If we want PHP to be as easy as possible then $nullref->bar(),
$foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions either -
they can just be notices.
> On Aug 28, 2019, at 4:01 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> Javascript has treated undefined variables as a catcha
This is where I think PHP may have broken us a little.
I just asked a few non-PHP developers here what they expect "(function () {
$a++; })()" to do, and they agreed it would be some sort of error. Got the
same answer for "(function () { $a->bar = 5; })() ".
Indeed, anyone who's used another C-li
$foo++ becoming 1 when $foo is undefined is not intuitive to me.
To take a very trivial example, that behaviour causes “for ($i = 0; $i < 10;
$I++) {}” to loop indefinitely.
> On Aug 28, 2019, at 6:52 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> This is where I think PHP may have broken us a li
I don’t think it’s helpful to compare C#’s BC policies to PHP’s. C# is used
today mostly as its architect intended at its founding. PHP, having
transitioned from a templating system to a fully-fledged language, is used
quite differently.
> On Aug 29, 2019, at 11:50 AM, Chase Peeler wrote:
>
>
- Agree on the usefulness of a stringable meta-type.
- Hack supports an explicit “: this” return type (without dollar) when
returning “new static(...)”. I think I might prefer that to “: static”.
- From a type perspective, I don’t understand the “int|void” idea - it might
make your users’ life
Without your contributions in the early 2000s, PHP likely would not enjoy
the popularity it does today.
But I don't think that gives you veto power over the entire process. You
haven't made any significant contributions to the codebase in over a
decade, and yet the language has still gained many m
>
> that don't fundamentally change the language
There's clearly a big disagreement about whether this is a fundamental
change or not.
Preventing something that the entire field of software engineering frowns
upon (and that most PHP developers avoid like the plague) doesn't seem like
a *fundamen
>
> What if Java suddenly said that all properties are suddenly private, and
> can only be accessed through getter/setter methods?
>
If Java announced that the next major version was to make the change after
95% of userland developers favoured it and over 2/3rds of their internals
team did, I'd th
I'm sure that some people wrote code like this, expecting it to always work
in PHP:
if ($some_condition) define("HELLO", 0);
if (HELLO) { var_dump("got here"); }
The equivalent, relying on buggy behaviour, PHP code looks like
if ($some_condition) $hello = 1;
if (!$hello) { var_dump("got here");
Though this is truly a stylistic complaint, I think it will lead to
harder-to-analyse code.
Currently I have a static analysis tool that can verify (in 99% of cases)
whether all properties of a class have been initialised in the constructor.
This check is even more important in PHP 7.4, where use
> As far as I know, the only viable way to do that is to make the array
> intrinsically typed, which means that types are validated when elements are
> inserted into the array, not when it is passed across a function boundary.
> In other words, array generics.
>
What if we left the array type alon
Someone recently requested something similar for a PHP static analysis tool
I wrote (https://psalm.dev/r/f75997a263), though that version only allows
lazy initialisation inside the class in which a given property is declared.
Personally I don't like either approach – I think per-property getters a
This proposal is great, but most PHP static analysis tools already do a
reasonable job of understanding by-reference assignment and detecting bugs
there (an exception is closure use by-reference checks, which is a
static-analysis no-man's land).
No static analysis tools catch your specific use-cas
This is expected behaviour given my understanding of how late static binding
works:
If there is a chain of “self::” calls that ultimately ends in
“static::someMethod”, then PHP behaves as if every preceding call was a call to
“static::”, not “self::”. In your second call you’re explicitly overr
For information that's needed at runtime (as opposed to documentation or
static analysis) docblocks have an obvious overh
I think the syntax here looks great, and I think this would be an exciting
addition to the language. I want to build things with it!
On Mon, 9 Mar 2020 at 10:43, Benjamin Eber
Saying "the syntax makes my eyes bleed" is slightly useless feedback.
You could say "it's hard to scan", but I don't even think that's true –
prepending everything << makes it easy to pick out attributes in plain text
at a glance, and one can assume that IDEs will help even further.
Additionally
r 9, 2020, at 9:48 PM, Mike Schinkel wrote:
>
>
>>
>> On Mar 9, 2020, at 9:36 PM, Matthew Brown wrote:
>>
>> Saying "the syntax makes my eyes bleed" is slightly useless feedback.
>
> That was just a header. There was elaboration right below it:
>
1 - 100 of 372 matches
Mail list logo
