I've always wondered why PHP didn't have a built in command or function
that behaved as `echo` but with a EOL.
I propose not to modify `print` or `echo` (as this was rightly pointed out
to cause b/c). How difficult would it be to add a new statement and/or
function to the PHP core called `say` / `s
\vsprintf($format . \PHP_EOL, $args);
> > }
> >
> > Jokes aside, this is so trivially achievable in userland that there is no
> > justification whatever for an internal function or functions, or
> > constructs, or opcodes.
> >
> > Cheers
> > Joe
>
(regardless of major version
changes) then PHP is overtly rigid and I predict it will ultimately become
extinct.
On Sun, Mar 3, 2019 at 3:34 AM Thomas Hruska
wrote:
> On 3/3/2019 1:45 AM, Ryan Jentzsch wrote:
> > Thanks for the explanation of b/c. I didn't know PHP is this rigid. Now I
&g
Is there a possibility this can be fixed in version 8? From
http://phpsadness.com/sad/30 listed as an outright bug (I don't have
the C skills to fix this. I am just raising this as an issue that has
been a criticism of PHP for many years now with a new major version
upcoming that could allow for a
BIG THUMBS UP for this feature.
As was mentioned that TypeScript uses this and saves developers lots of
time by avoiding nested null checking.
I suggest in the RFC including a list of other languages that have this
feature.
On Tue, Jun 2, 2020, 2:53 PM Ilija Tovilo wrote:
> Hi internals
>
> I'd
With over 25+ years of software development experience it was In 2016 I was
introduced to the world of PHP development.
One day I came across the most unusual of error messages
"T_PAAMAYIM_NEKUDOTAYIM" What the hell is this?!?
That I needed to waste my time to Google this is simply insane. At the t
OMG the trolling continues even today with this nonsense. Disappointing.
Calling T_PAAMAYIM_NEKUDOTAYIM a non-issue is simply wrong and here's why::
"People don’t ask for the other parse errors even half as often as they as
for T_PAAMAYIM_NEKUDOTAYIM They do so because it looks like gibberish to
th
Why is there a 15 byte limit in the first place?
On Wed, Jun 24, 2020, 1:22 PM tyson andre wrote:
>
> Hi internals,
>
> By default, strings in parameter lists are truncated to 15 bytes by
> default in Throwable->getTraceAsString()
> (and Throwable->__toString() as a consequence).
> (in Zend/zend
https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/
Is there a process in place for RFCs that address bugs in bugs.php.net if
they have a passing vote to mark the bug as "FIXED in version xx.xx.xx" or
if the RFC doesn't pass mark the bug as "WONTFIX"?
On Mon, Jul 26, 2021 at 6:49 AM Peter Cowburn
wrote:
> >
> > On Jul 6, 2021, at 08:34, Daniel Be
Answering the question: How do other languages handle this problem? Or how
do they avoid it in
the first place?
Python basically doesn't handle the problem at all and offers this advice: Be
sure to delete all debugging related code before code delivery!
See section [9.2.1 production code cannot c
`number` type But frankly this seems a bit silly and reminds me too much of
JavaScript.
On Wed, Sep 28, 2022, 9:08 PM Hamza Ahmad
wrote:
> Hi Olle,
>
> I appreciate your idea of introducing a similar concept of typedef.
> What if you write an RFC explaining that concept. I can join you
> however
This may be a dumb question...I was under the impression that including the
config switches for the databases such as MySQL, SQLite, Postgres, etc.
that ONLY the PDO bindings are included NOT the database client itself.
Is this the case with the exception of SQLite? In other words is the
version o
I can't count how many times I've been bitten by this. From the infamous
fractal blog:
"Parts of PHP are practically designed to produce buggy code.
json_decode returns null for invalid input, even though null is also a
perfectly valid object for JSON to decode to—this function is completely
unrel
I am aware of Advanced PHP debugger but what I need this type of
functionality for is mocking and testing.
As an example I want to use PHPUnit mocking feature to create a mock of a
class. However in the constructor of this class is the following line to
get the expected JSON string:
$result = fil
I am trying to look up and/or enter a bug report:
downforeveryoneorjustme.com reports:
Is bugs.php.net down?
It's not just you! bugs.php.net looks down from here.
I agree with Michael (to a large degree) and I think I see clearly
Michael's point:
Under the current system I will NEVER create an RFC (or find someone with
the Zend engine coding chops to help me) because the RISK vs. REWARD with
the current RFC system is too likely to be a colossal waste of ever
In my opinion The Strong Typing Syntax RFC will have less of a chance of
passing a vote than https://wiki.php.net/rfc/typed-properties.
Since the typed-properties RFC was confined to properties on a class (and
looking at the code it appears to me that it wasn't too difficult to
implement the type s
Why would something like this not work?
strict class MyClass
{
protected int $foo = 1;
public string $bar = "strict keyword in front of class allows/enforces
strict properties";
private string $isItReallyThatDifficult = "to implement this?";
}
On Tue, Jun 5, 2018 at 4:17 PM, Rowan Col
that is reasonable to code and
implement.
Also, can anyone in internals respond to this inquiry?
https://github.com/php/php-src/pull/1797#issuecomment-394434391
On Wed, Jun 6, 2018 at 4:00 AM Rowan Collins
wrote:
> On 6 June 2018 at 07:14, Ryan Jentzsch wrote:
>
>> Why would someth
20 matches
Mail list logo
