Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Григорий Senior PHP / Разработчик Web]

Thanks for suggestion about assert() use cases, i know it exists before,
but never used.

Usually if something shouldn't happen i throw exception there, or at least
type control. Its like manual mark for the future - you doing something
wrong, fix it.

Error collection case its about "you're right, but external system doesnt
think so".

Example 1:
i send correctly and valid first name (for my system) to external system.
That system reported thats name contains character outside its regular
expression. I can solve it in-place creating function with regular
expression that change invalid chars to question marks and case will be
covered.

Example 2:
My system result is less than zero. Remote system expects greater than
zero. I cant just validate/sanitize data to greater than zero. If i send
single operation - it could be the exception. But there could be two cases
- multiple operations (commands) queue or bulk operation (one command, few
rows of different data). In first case i have to stop all operation,
exception could help me. In second case same error becomes to warning, and
one row should not stop whole process, but have to report me. So previously
i solved it with exception, and now exception shots my legs. Thats why i
use exceptions only if something wrong on developer/user side, and never to
system-system cases. if() still powerful.

ср, 7 февр. 2024 г. в 03:55, Alex Wells :

> On Tue, Feb 6, 2024 at 7:14 PM Larry Garfield 
> wrote:
>
> > These two samples *are logically identical*, and even have mostly the
> same
> > performance characteristics, and both expose useful data to static
> > analyzers.  They're just spelled differently.  The advantage of the
> second
> > is that it could be implemented without generics.  (ADTs would be an
> > optional nice-to-have.)  And if the caller doesn't handle DivByZero, it
> > would try to pass it up to its caller, but being checked it would require
> > the caller to also declare that it can raise DivByZero.
> >
>
> Let's assume that the developer knows the divisor isn't 0 - through an
> assertion or an `if` clause above the call to `divide(5, $divisor)`. In
> this case, DivByZero error cannot ever be thrown (or risen), but the
> developer would still have to either handle the error (which will never
> happen) or declare it as raisable, which in turn may require also marking
> 10+ function/method calls as "raises DivByZero". Both options aren't great.
>
> And even if there was no assertion about the divisor, maybe the developer's
> intent is exactly to ignore that case as an "implicit assertion" - meaning
> instead of explicitly asserting the divisor value themselves (through
> `assert($divisor !== 0)`), they rely on `divide(5, $divisor)` doing that
> implicitly for them. If the `assert()` fails, then nobody is expected to
> really handle that assertion error; it usually bubbles up to the global
> exception handler which takes care of it. If the `divide()` fails on the
> other hand, checked exceptions would require all the callers to actually
> "check" it by catching or declaring the caller function as `raises
> DivByZero`, but this doesn't bring any benefit to the developer in this
> case.
>
> So I assume this is why Java developers hate checked exceptions and why
> Kotlin doesn't have them. I'm not aware of other implementations of checked
> exceptions; there may be other, better versions of them. If you have any in
> mind that overcome the issues above, I'd be interested to look into them :)
>


-- 
+375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи
https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
6562...@gmail.com

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

[Tim Starling]

On 7/2/24 13:43, Ayesh Karunaratne wrote:


Hi Tim,
Now that the RFC is restarted, could you mention some examples in 
Georgian that might be good test cases?


I was thinking there might be some good test cases in Turkish, but 
couldn't find any. The RFC has examples 
(https://github.com/php/php-src/pull/13161) in Vietnamese, but they 
are correct for both "uppercase first character" and titlecase 
conversions.


Any Georgian word would do. Your ASCII test case is "abc". The 
Georgian equivalent for that would be "აბგ" (ani bani gani, U+10D0 
U+10D1 U+10D2) which should remain the same after passing through 
mb_ucfirst(). Compare mb_strtoupper("აბგ") -> "ᲐᲑᲒ" (U+1C90 U+1C91 
U+1C92).


On the task I mentioned that ligatures are also affected. I gave the 
example mb_ucfirst("lj") -> "Lj", that is, U+01C9 -> U+01C8. You could 
add a test case for that. Compare mb_strtoupper("lj") -> "LJ" (U+01C7).


To repeat my rationale -- we can view ucfirst() either through a 
technical lens (convert the first character of a string to upper case) 
or through a natural language lens (convert a string to sentence case, 
with the initial letter capitalised per local conventions). I am 
arguing to make mb_ucfirst() be a natural language extension of 
ucfirst(), because applying the technical extension would produce 
results that look quite jarring in a natural language context.


There are some edge cases which are not quite right. To really do a 
good job, a new case map will be needed. But if we document it as 
being for natural language, and set the right expectations, we can fix 
the edge cases later.


-- Tim Starling

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

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

[Ayesh Karunaratne]

> > I see. I'll change mb_ucfirst using titlecase.
>
> Per my comments a month ago on the GitHub issue , I think it is much
> better to use title case for mb_ucfirst() than to use upper case,
> since conversion of the first character to upper case has the effect
> of corrupting text in the Georgian script, and initial lower-case
> ligatures are converted to a form which appears like two upper case
> letters. So I'm pleased to see this change to the PR.
>
> I would appreciate it if the RFC could also be updated to include this
> detail, since my vote depends on whether title case or upper case will
> be used.
>
> -- Tim Starling
>

Hi Tim,
Now that the RFC is restarted, could you mention some examples in Georgian
that might be good test cases?

I was thinking there might be some good test cases in Turkish, but couldn't
find any. The RFC has examples (https://github.com/php/php-src/pull/13161)
in Vietnamese, but they are correct for both "uppercase first character"
and titlecase conversions.

Thank you.

>

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Alex Wells]

On Tue, Feb 6, 2024 at 7:14 PM Larry Garfield 
wrote:

> These two samples *are logically identical*, and even have mostly the same
> performance characteristics, and both expose useful data to static
> analyzers.  They're just spelled differently.  The advantage of the second
> is that it could be implemented without generics.  (ADTs would be an
> optional nice-to-have.)  And if the caller doesn't handle DivByZero, it
> would try to pass it up to its caller, but being checked it would require
> the caller to also declare that it can raise DivByZero.
>

Let's assume that the developer knows the divisor isn't 0 - through an
assertion or an `if` clause above the call to `divide(5, $divisor)`. In
this case, DivByZero error cannot ever be thrown (or risen), but the
developer would still have to either handle the error (which will never
happen) or declare it as raisable, which in turn may require also marking
10+ function/method calls as "raises DivByZero". Both options aren't great.

And even if there was no assertion about the divisor, maybe the developer's
intent is exactly to ignore that case as an "implicit assertion" - meaning
instead of explicitly asserting the divisor value themselves (through
`assert($divisor !== 0)`), they rely on `divide(5, $divisor)` doing that
implicitly for them. If the `assert()` fails, then nobody is expected to
really handle that assertion error; it usually bubbles up to the global
exception handler which takes care of it. If the `divide()` fails on the
other hand, checked exceptions would require all the callers to actually
"check" it by catching or declaring the caller function as `raises
DivByZero`, but this doesn't bring any benefit to the developer in this
case.

So I assume this is why Java developers hate checked exceptions and why
Kotlin doesn't have them. I'm not aware of other implementations of checked
exceptions; there may be other, better versions of them. If you have any in
mind that overcome the issues above, I'd be interested to look into them :)

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Weedpacket]

On 2024-02-07 09:08, Larry Garfield wrote:


"The right tool for the job" is indeed the strongest argument for lightweight 
exceptions.  It's a tool we lack right now.

I'm thinking not of "DB went away" type issues (Exceptions are already fine there), but 
"requested product not found."  Right now, the options we have are:

...

The first is probably most common, but null (as I go into in the article) 
doesn't tell you anything and leads to mismatch errors.

Exceptions, I'd argue, are just plain wrong in this situation.  (Which means, 
yes, all the frameworks that throw exceptions on route-not-found are doing it 
wrong.)

And the union-enum approach is a bit clunky as it has no native language support, and no 
solid conventions behind it.  This is my preferred approach personally today, but I think 
we can do better.  Even just having this available at all means that "well everyone 
just uses unchecked exceptions" isn't entirely true.  (All three of the above can be 
found in the wild.)



I can add a fourth option for the "get record by ID" that may not be 
found, that I've seen in the wild:


public function find($id): ProductSet {}

Where the ProductSet is a collection of (in this case) no more than one 
Product. It's up to the caller to verify there actually is a Product 
inside and extract it, and it's also the caller's decision whether not 
finding one is a problem or not.


Of course, in this domain it folded in with using ProductSets to 
represent more general collections of Products and the resulting set 
algebra.


Weedpacket

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

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Larry Garfield]

On Tue, Feb 6, 2024, at 7:56 PM, Григорий Senior PHP / Разработчик Web wrote:
> Thanks Larry, I will read both articles next weekend.
>
> Am not even talking about changing `throw` to `raise`.
>
> Am talking only about:
> - production ready code
> - that should be able to refactor with error collectors (that was not
> implemented years ago)
> - without touching return types
> - without touching input arguments of existing code
> - without possible code fall after throw exception: you have to try/catch
> all places you use that function (sometimes you predict possible error, and
> yes, write return class/enum to extend/refactor it later)
> (and yes, if old code did not support returning null/null-object before -
> you have to refactor return types then)
>
> While working with queues you have a list of tasks
> - then you reduce it to smaller with reducer (unique/filter/merge)
> - then do some queries
> - then walk initial data using reduced results: copying reports to save
> errors/warnings to each task separately
>
> It cannot be solved with exceptions. In addition, large arrays throw
> exceptions that cause timeloss. It's definitely not a tool for.
> Also your method could return many errors (today - only one
> error/exception), and you need to write a second method, then call the
> second method, then debug the second method.
>
> So what's in rest? Arrays collection of warnings and errors. Changing
> return types or passing second-return by reference.
>
> [ Enum case ~ DTO output ] covers newly written code. Old code is
> uncovered. You have to rewrite a full tree, that's why some trick is
> necessary.
>
> I did it my way with an error bag stack. I enable it inside the function or
> in place I call the function. I want to share this experience, and imagined
> it would be better for all users. It could be done without 2 classes, 10
> functions and work with push/pop/current (closer to ob_start/ob_get_clean
> story).
> I guess it could be implemented if `raise` world will put any data to the
> current error bag in the stack. Exactly if the current error bag is present
> (declared manually like you can declare() strict types or ticks for some
> scope).
>
> I agree that there's more mandatory problems to solve that I didn't even
> know about.
> I tried to talk about error handling with a few developers, all of them
> recommend:
> 1. Use exceptions, don't make anything fresh
> 2. Do validation at the script start to reduce the count of errors later
>
> I've just encountered cases where bugs come from within - once you
> integrate a really bad external system with its own checks, which are
> described in hundreds of documents, I'm sure you'll encounter new bugs once
> the "working" code is released to production. And then you will need to
> quickly and easily reorganize it.
>
> And you can't.
> And you will be sad.
> And, "PHP moves differently" is a completely wrong principle, I believe in
> "watching for".
I think there's a subtle but important difference here between what you're 
describing as the problem and what you implied the solution was (which I then 
ran with).

What you're talking about is trying to change the error handling model of 
existing code without changing function signatures.  There are only two 
possible ways to do that, both of them bad: Unchecked exceptions and globals.

What I described, based on the syntax you offered, is checked exceptions, which 
necessarily means changing the function signature.  Error handling is part of 
the contract of a function.  If its error handling changes, it *should* have a 
signature change to indicate that.  (That unchecked exceptions do not do that 
is the problem with unchecked exceptions.)  So if "no changes to existing code" 
is the goal, checked exceptions as I describe them are not the answer you are 
looking for.

It seems from your latest message that you're describing more a generalized 
version of `json_last_error()` and similar functions.  The problem there is 
that such an API design is generally considered very poor practice outside of 
C, because it's all necessarily based on globals and "hope you remembered to 
check the thing that no one told you to check and is not even slightly obvious 
to check".  That is not something I would want better support for in the 
language at all.  There's probably cleaner ways to emulate it in user-space, 
but that is for a particular application to sort out.  There's definitely 
cleaner monadic solutions (which I've written before and are quite neat) using 
a writer/logger monad, but that again doesn't meet your "don't change existing 
code" requirement.  I don't think anything the language can do will meet that 
requirement and be a good design.

--Larry Garfield

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

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

[youkidearitai]

2024年2月7日(水) 4:49 youkidearitai :
>
> 2024年2月7日(水) 2:56 Juliette Reinders Folmer 
> :
> >
> > On 6-2-2024 3:40, youkidearitai wrote:
> > > 2024年2月6日(火) 8:33 Tim Starling :
> > >> On 2/2/24 20:27, youkidearitai wrote:
> > >>
> > >> I see. I'll change mb_ucfirst using titlecase.
> > >>
> > >> Per my comments a month ago on the GitHub issue , I think it is much 
> > >> better to use title case for mb_ucfirst() than to use upper case, since 
> > >> conversion of the first character to upper case has the effect of 
> > >> corrupting text in the Georgian script, and initial lower-case ligatures 
> > >> are converted to a form which appears like two upper case letters. So 
> > >> I'm pleased to see this change to the PR.
> > >>
> > >> I would appreciate it if the RFC could also be updated to include this 
> > >> detail, since my vote depends on whether title case or upper case will 
> > >> be used.
> > >>
> > >> -- Tim Starling
> > > Hi, Tim
> > >
> > > Thank you for your comment.
> > > I modified to "uses unicode case title" in an RFC.
> > >
> > > Regards
> > > Yuya
> > >
> >
> > Help me out here, but doesn't changing what is actually proposed in an
> > RFC **after** the vote has started invalidate the vote ?
> >
> > Shouldn't the vote be closed/withdrawn and restarted in that case ?
>
> Hi, Internals.
>
> Juliette, Thank you for pointing.
> I'm mistake.
>
> I checked the following and it was exactly as I said.
> https://wiki.php.net/RFC/voting#voting
>
> > A valid voting period must be declared when voting is started and must not 
> > be changed during the vote.
>
> I broke this rule. In this case, should I return to "Under discussion"?
> I apologize to those who voted, admitting lack of discussion, I want
> to reorganize.
>
> Regards
> Yuya

Hi, Internals.
This an RFC is revert to "Under Discussion".

https://wiki.php.net/rfc/howto
Referenced Section 7.3:
> A serious issue with your RFC needs to be addressed: update the status of 
> your RFC page and its section on https://wiki.php.net/RFC to “Under 
> Discussion” and continue again from step 5.

I would like to wait another two weeks to vote again.
Scheduled for February 21st, GMT 00:00 restart voting.

Please feel free to comment.

I apologize to everyone who voted again.

Regards
Yuya

-- 
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-

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

[PHP-DEV] Why are serialized strings wrapped in double quotes? (s::"")

[Sanford Whiteman]

Howdy all, haven't posted in ages but good to see the list going strong.

I'd like a little background on something we've long accepted: why
does the serialization format need double quotes around a string, even
though the byte length is explicit?

Example:

  s:5:"hello";

All else being equal I would think we could have just

  s:5:hello;

and skip forward 5 bytes. Instead we need to be aware of the leading
and trailing " in our state machine but I'm not sure what the
advantage is.

Was this just to make strings look more 'stringy', even though the
format isn't meant to be human-readable?

I read (the archive of) Kris's blog post:

  
https://web.archive.org/web/20170813190508/http://blog.koehntopp.info/index.php/2407-php-understanding-unserialize/

but that didn't shed any light. Zigzagging through the source wasn't
getting me there as fast as someone who was there from the beginning.

The reason for my question is I'm writing a blog post about a SaaS app
that (don't gasp/laugh) returns serialize() format from one of its
APIs. In discussing why the PHP format can make sense vs. JSON, I
wanted to point to the faster parsing you get with length-prefixed
strings. Then I started wondering about why we have both the length
prefix and the extra quotes.

Thanks,

Sandy

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

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Arvids Godjuks]

On Tue, 6 Feb 2024 at 22:09, Larry Garfield  wrote:

> On Tue, Feb 6, 2024, at 7:18 PM, Arvids Godjuks wrote:
>
> >> To be clear: I really like this concept and have discussed it with
> others
> >> before, using almost exactly this syntax.  I have not proposed it
> because
> >> my read of Internals lately is that there's no stomach for more
> >> type-centric behavior, especially with the obvious "But we already have
> >> exceptions, what's yer problem?" response (which is valid to a point,
> but
> >> also incomplete for reasons explained above).  The responses in this
> thread
> >> so far confirm that fear, but as an optimist I'd be very happy to be
> proven
> >> wrong if there is an appetite for improving error handling via the type
> >> system.
> >>
> >> Absent that, union types and enums (or really any interfaced object) or
> a
> >> purpose-built Either object are the best options today, and while
> they're
> >> not ideal, they're not bad options either.
> >>
> >> None of that logic or argument requires sh*tting on OOP as a concept or
> >> abusing others on the list, however.  Doing that only undermines the
> valid
> >> point that there is ample headroom to improve PHP's error handling.
> >>
> >> --Larry Garfield
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: https://www.php.net/unsub.php
> >>
> >>
> > Thank you Larry for this interesting summary - didn't remember there was
> > quite a bit a discussion around the topic prior.
> >
> > I lean on the "we have exceptions, just leave it be" side out of
> practical
> > reasons - the vast majority of OO code has standardized around the
> approach
> > and interoperability is high. It makes using code that's out there super
> > easy and predictable - almost nobody uses the "return false|0|-1" out
> there
> > (at least I haven't used code like that except the PHP's stdlib, and even
> > that has been changing little by little). It makes error handling
> > predictable, and considering the type of code we mostly write in PHP -
> most
> > of the time we leave the catching to the global top-level handler or
> > sentry/bugsnag/etc libraries.
> > Consistency is the word I want to highlight here. For better or for
> worse -
> > it's the method the PHP ecosystem arrived at and it's the predominant
> one.
> > Introducing a distinctly different method of error handling is going to
> > bring in wrappers around libraries that convert errors to one style or
> the
> > other, the application code can end up using different ways of error
> > handling, etc, etc. My approach is to grab a different language aka "the
> > right tool for the job" if I want to build things differently, that's why
> > we have so many programming languages and not just a few :)
> >
> > I'd put resources into optimising the VM and php engine to handle the
> > exceptions better and if there are improvements to be had there - do
> those
> > maybe? (I suspect JIT is also going to influence this a lot going
> forward).
>
>
> "The right tool for the job" is indeed the strongest argument for
> lightweight exceptions.  It's a tool we lack right now.
>
> I'm thinking not of "DB went away" type issues (Exceptions are already
> fine there), but "requested product not found."  Right now, the options we
> have are:
>
> public function find($id): ?Product {}
>
> public function find($id): Product {
> // This is very expensive I don't think will ever not be.
> // It will also bubble up to the top of the application and crash the
> whole process,
> // Or still show up in weird, unexpected places.
> throw new NotFound();
> }
>
> public function find($id): Product|RepoError {}
> enum RepoError {
> case NotFound;
> }
>
> The first is probably most common, but null (as I go into in the article)
> doesn't tell you anything and leads to mismatch errors.
>
> Exceptions, I'd argue, are just plain wrong in this situation.  (Which
> means, yes, all the frameworks that throw exceptions on route-not-found are
> doing it wrong.)
>
> And the union-enum approach is a bit clunky as it has no native language
> support, and no solid conventions behind it.  This is my preferred approach
> personally today, but I think we can do better.  Even just having this
> available at all means that "well everyone just uses unchecked exceptions"
> isn't entirely true.  (All three of the above can be found in the wild.)
>
> --Larry Garfield
>

And that, folks, is how you change people's minds.

I'm on board, Larry. I agree that things like route not found, entity not
found and so on don't have to be full-fat exceptions - in those cases, you
indeed don't need the stack trace and other parts of it. Even the error
message might not be required since whatever you "throw" or "raise" in this
case is self-explanatory just by its type/object/enum type.

-- 

Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Larry Garfield]

On Tue, Feb 6, 2024, at 7:18 PM, Arvids Godjuks wrote:

>> To be clear: I really like this concept and have discussed it with others
>> before, using almost exactly this syntax.  I have not proposed it because
>> my read of Internals lately is that there's no stomach for more
>> type-centric behavior, especially with the obvious "But we already have
>> exceptions, what's yer problem?" response (which is valid to a point, but
>> also incomplete for reasons explained above).  The responses in this thread
>> so far confirm that fear, but as an optimist I'd be very happy to be proven
>> wrong if there is an appetite for improving error handling via the type
>> system.
>>
>> Absent that, union types and enums (or really any interfaced object) or a
>> purpose-built Either object are the best options today, and while they're
>> not ideal, they're not bad options either.
>>
>> None of that logic or argument requires sh*tting on OOP as a concept or
>> abusing others on the list, however.  Doing that only undermines the valid
>> point that there is ample headroom to improve PHP's error handling.
>>
>> --Larry Garfield
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>>
> Thank you Larry for this interesting summary - didn't remember there was
> quite a bit a discussion around the topic prior.
>
> I lean on the "we have exceptions, just leave it be" side out of practical
> reasons - the vast majority of OO code has standardized around the approach
> and interoperability is high. It makes using code that's out there super
> easy and predictable - almost nobody uses the "return false|0|-1" out there
> (at least I haven't used code like that except the PHP's stdlib, and even
> that has been changing little by little). It makes error handling
> predictable, and considering the type of code we mostly write in PHP - most
> of the time we leave the catching to the global top-level handler or
> sentry/bugsnag/etc libraries.
> Consistency is the word I want to highlight here. For better or for worse -
> it's the method the PHP ecosystem arrived at and it's the predominant one.
> Introducing a distinctly different method of error handling is going to
> bring in wrappers around libraries that convert errors to one style or the
> other, the application code can end up using different ways of error
> handling, etc, etc. My approach is to grab a different language aka "the
> right tool for the job" if I want to build things differently, that's why
> we have so many programming languages and not just a few :)
>
> I'd put resources into optimising the VM and php engine to handle the
> exceptions better and if there are improvements to be had there - do those
> maybe? (I suspect JIT is also going to influence this a lot going forward).


"The right tool for the job" is indeed the strongest argument for lightweight 
exceptions.  It's a tool we lack right now.

I'm thinking not of "DB went away" type issues (Exceptions are already fine 
there), but "requested product not found."  Right now, the options we have are:

public function find($id): ?Product {}

public function find($id): Product {
// This is very expensive I don't think will ever not be.
// It will also bubble up to the top of the application and crash the whole 
process,
// Or still show up in weird, unexpected places.
throw new NotFound();
} 

public function find($id): Product|RepoError {}
enum RepoError {
case NotFound;
}

The first is probably most common, but null (as I go into in the article) 
doesn't tell you anything and leads to mismatch errors.

Exceptions, I'd argue, are just plain wrong in this situation.  (Which means, 
yes, all the frameworks that throw exceptions on route-not-found are doing it 
wrong.)

And the union-enum approach is a bit clunky as it has no native language 
support, and no solid conventions behind it.  This is my preferred approach 
personally today, but I think we can do better.  Even just having this 
available at all means that "well everyone just uses unchecked exceptions" 
isn't entirely true.  (All three of the above can be found in the wild.)

--Larry Garfield

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

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

[Saki Takamachi]

> There's been discussion recently about how to deal with incompatibilities 
> between different PDO drivers, especially now that we can have subclasses per 
> driver.  That may be the way to deal with it.  I don't have a major opinion 
> on the approach, other than all incompatibilities should be handled in a 
> consistent way.

I was thinking of an implementation method like `lastInsertId()`, but there is 
certainly another way to use a subclass.

Personally, I was thinking of implementing, for example, SQL99-compliant 
(included) functions in PDO Core Class, and vendor-specific original functions 
in subclasses. However, I don't have a strong opinion on how they should be 
used, as there is still not much precedent for subclasses.

I agree with you that it should be a consistent implementation. I'm not sure if 
all incompatible features should be implemented in subclasses, or just 
vendor-specific features, but at least yes. There should be consistency.

Regards.

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

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Григорий Senior PHP / Разработчик Web]

Thanks Larry, I will read both articles next weekend.

Am not even talking about changing `throw` to `raise`.

Am talking only about:
- production ready code
- that should be able to refactor with error collectors (that was not
implemented years ago)
- without touching return types
- without touching input arguments of existing code
- without possible code fall after throw exception: you have to try/catch
all places you use that function (sometimes you predict possible error, and
yes, write return class/enum to extend/refactor it later)
(and yes, if old code did not support returning null/null-object before -
you have to refactor return types then)

While working with queues you have a list of tasks
- then you reduce it to smaller with reducer (unique/filter/merge)
- then do some queries
- then walk initial data using reduced results: copying reports to save
errors/warnings to each task separately

It cannot be solved with exceptions. In addition, large arrays throw
exceptions that cause timeloss. It's definitely not a tool for.
Also your method could return many errors (today - only one
error/exception), and you need to write a second method, then call the
second method, then debug the second method.

So what's in rest? Arrays collection of warnings and errors. Changing
return types or passing second-return by reference.

[ Enum case ~ DTO output ] covers newly written code. Old code is
uncovered. You have to rewrite a full tree, that's why some trick is
necessary.

I did it my way with an error bag stack. I enable it inside the function or
in place I call the function. I want to share this experience, and imagined
it would be better for all users. It could be done without 2 classes, 10
functions and work with push/pop/current (closer to ob_start/ob_get_clean
story).
I guess it could be implemented if `raise` world will put any data to the
current error bag in the stack. Exactly if the current error bag is present
(declared manually like you can declare() strict types or ticks for some
scope).

I agree that there's more mandatory problems to solve that I didn't even
know about.
I tried to talk about error handling with a few developers, all of them
recommend:
1. Use exceptions, don't make anything fresh
2. Do validation at the script start to reduce the count of errors later

I've just encountered cases where bugs come from within - once you
integrate a really bad external system with its own checks, which are
described in hundreds of documents, I'm sure you'll encounter new bugs once
the "working" code is released to production. And then you will need to
quickly and easily reorganize it.

And you can't.
And you will be sad.
And, "PHP moves differently" is a completely wrong principle, I believe in
"watching for".

-- 
+375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи
https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
6562...@gmail.com

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

[youkidearitai]

2024年2月7日(水) 2:56 Juliette Reinders Folmer :
>
> On 6-2-2024 3:40, youkidearitai wrote:
> > 2024年2月6日(火) 8:33 Tim Starling :
> >> On 2/2/24 20:27, youkidearitai wrote:
> >>
> >> I see. I'll change mb_ucfirst using titlecase.
> >>
> >> Per my comments a month ago on the GitHub issue , I think it is much 
> >> better to use title case for mb_ucfirst() than to use upper case, since 
> >> conversion of the first character to upper case has the effect of 
> >> corrupting text in the Georgian script, and initial lower-case ligatures 
> >> are converted to a form which appears like two upper case letters. So I'm 
> >> pleased to see this change to the PR.
> >>
> >> I would appreciate it if the RFC could also be updated to include this 
> >> detail, since my vote depends on whether title case or upper case will be 
> >> used.
> >>
> >> -- Tim Starling
> > Hi, Tim
> >
> > Thank you for your comment.
> > I modified to "uses unicode case title" in an RFC.
> >
> > Regards
> > Yuya
> >
>
> Help me out here, but doesn't changing what is actually proposed in an
> RFC **after** the vote has started invalidate the vote ?
>
> Shouldn't the vote be closed/withdrawn and restarted in that case ?

Hi, Internals.

Juliette, Thank you for pointing.
I'm mistake.

I checked the following and it was exactly as I said.
https://wiki.php.net/RFC/voting#voting

> A valid voting period must be declared when voting is started and must not be 
> changed during the vote.

I broke this rule. In this case, should I return to "Under discussion"?
I apologize to those who voted, admitting lack of discussion, I want
to reorganize.

Regards
Yuya

-- 
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-

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

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Jordan LeDoux]

On Tue, Feb 6, 2024 at 11:19 AM Arvids Godjuks 
wrote:

> On Tue, 6 Feb 2024 at 19:14, Larry Garfield 
> wrote:
>
> Thank you Larry for this interesting summary - didn't remember there was
> quite a bit a discussion around the topic prior.
>
> I lean on the "we have exceptions, just leave it be" side out of practical
> reasons - the vast majority of OO code has standardized around the approach
> and interoperability is high. It makes using code that's out there super
> easy and predictable - almost nobody uses the "return false|0|-1" out there
> (at least I haven't used code like that except the PHP's stdlib, and even
> that has been changing little by little). It makes error handling
> predictable, and considering the type of code we mostly write in PHP - most
> of the time we leave the catching to the global top-level handler or
> sentry/bugsnag/etc libraries.
> Consistency is the word I want to highlight here. For better or for worse -
> it's the method the PHP ecosystem arrived at and it's the predominant one.
> Introducing a distinctly different method of error handling is going to
> bring in wrappers around libraries that convert errors to one style or the
> other, the application code can end up using different ways of error
> handling, etc, etc. My approach is to grab a different language aka "the
> right tool for the job" if I want to build things differently, that's why
> we have so many programming languages and not just a few :)
>
> I'd put resources into optimising the VM and php engine to handle the
> exceptions better and if there are improvements to be had there - do those
> maybe? (I suspect JIT is also going to influence this a lot going forward).
>
> Sincerely,
> Arvīds Godjuks
>

When what you have is a situation where a function or block of code goes "I
know something fixable went wrong, but only the block above me in the
execution stack knows what to do about it", Exceptions are extremely
overkill. But they are the only "sane" option in PHP in a lot of situations.

PHP simply doesn't have a language level structure to handle this VERY
COMMON situation. The fact that people have standardized on Exceptions for
this is not a point in favor of Exceptions. It is a sign of how much extra
performance and semantic correctness we COULD provide to the language by
improving this area of error handling.

I don't know if the OP of this email thread was referring to this
situation. It was honestly very difficult for me to follow what they were
even asking for given the language barrier. But I am 1000% behind the
problem space that Larry is describing. Exceptions are not a solution to
that problem, they are duct tape.

Jordan

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Arvids Godjuks]

On Tue, 6 Feb 2024 at 19:14, Larry Garfield  wrote:

> On Tue, Feb 6, 2024, at 4:13 PM, Григорий Senior PHP / Разработчик Web
> wrote:
> > Btw, i agree about Javascript, but on a low level it produces the most
> > clean code, because there's no types and rules. All types moved to
> > TypeScript's client side compiler.
> >
> > JS 15 years ago ACCIDENTALLY created a pipeline. Named it "Promise". We
> > spent years after to understand that while (true) and then/catch should
> be
> > different patterns.
>
> I assume much of this thread is a language-barrier issue, which is making
> it more hostile than it needs to be.  So let me try and expand a bit,
> because I am actually quite sympathetic to the OP's request, though not the
> way it's being made.
>
> First of all, please don't top post.  It is considered rude on this list.
> GMail makes it a bit annoying to bottom post but it can be done.  Please do
> so.
>
> Second, there's considerable prior art and discussion on the topic of
> error handling and exceptions.  In particular, I recommend this excellent
> article by Joe Duffy:
>
> https://joeduffyblog.com/2016/02/07/the-error-model/
>
> And this one from me:
>
> https://peakd.com/hive-168588/@crell/much-ado-about-null
>
> Yes, they're long, but error handling is a topic that requires more than
> casual thought.
>
> To summarize the articles for the short of time:
>
> * Exceptions in many languages (including PHP) are very expensive. The
> stack trace is one of the most expensive things PHP does.  This is one of
> the reasons why exceptions are terrible for flow control.
> * Unchecked exceptions (where a function doesn't define what it can throw)
> are a great way to break your application in exciting and unpredictable
> ways.  (This is the other reason exceptions are terrible for flow control.)
> * Many people find checked exceptions cumbersome, even though they are
> better (for reasons Duffy goes into).  This is due mostly to bad design of
> checked exceptions in JVM languages.
> * The real problem is that we have a channel for a success case (return
> value), a channel for catastrophic failure (exceptions), but no channel for
> mundane errors (things a responsible developer should expect and know how
> to handle gracefully).  So those get shoved into one or the other, usually
> an exception.
>
> The need is for a "mundane error" channel.  I agree with this.  Different
> languages handle it in different ways.
>
> * Go has multi-returns.
> * Rust has the Result type (which is an Either monad), and an
> auto-propagation operator (?).
> * PHP has union types (though that's not a deliberate design, just an
> emergent one).
>
> One of the key differences between different approaches is whether they
> force you to handle error cases (Result type) or let you ignore errors and
> assume a happy path (Go, PHP), letting an unhappy path just explode later
> on.  Whether the language should force you to think about unhappy paths is
> a complex and subjective question that I won't delve into now beyond saying
> that there's valid arguments and use cases for both designs.
>
> As noted in the article above, I've started using enums and union type
> returns a lot for error handling and it's pretty nice, all things
> considered.  That works today in all supported PHP verisons (8.1+).  That
> said, it's not perfect, in part because it's not standardized and there's
> no really good language-level automation around it.
>
> If we had generics and ADTs, building a Rust-like Result type would be
> super easy, and I'd suggest we include one in the stdlib for consistency.
> We'll probably get ADTs eventually, but generics are not something I'd bank
> on, so that is out.
>
> HOWEVER, and this is where the important part lies, an open, lightweight,
> checked exception system is isomorphic to a Result object.  It's just
> unwrapped.  Compare these hypotheticals:
>
> class DivByZero {}
> (this could also be an enum case, but being generic for now.)
>
> function divide(float $a, float $b): Result
> {
> if ($b === 0) return new Result::Err(new DivByZero());
>return new Result::OK($a/$b);
> }
>
> $result = divide(5, 0);
> $x = match ($result) {
>   is Result::OK($x) => $x,
>   is Result::Err => // Do some kind of error handling.
> }
>
> vs.
>
> function divide(float $a, float $b): int raises DivByZero
> {
> if ($b === 0) raise new DivByZero();
>return new $a/$b;
> }
>
> try {
>   $result = divide(5, 0);
>   // Do stuff with $result, knowing it is valid.
> } catch (DivByZero) {
>   // Do some kind of error handling.
> }
>
> These two samples *are logically identical*, and even have mostly the same
> performance characteristics, and both expose useful data to static
> analyzers.  They're just spelled differently.  The advantage of the second
> is that it could be implemented without generics.  (ADTs would be an
> optional nice-to-have.)  And if the caller doesn't handle DivByZero, it
> would try to pass it up to its 

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

[Juliette Reinders Folmer]

On 6-2-2024 3:40, youkidearitai wrote:

2024年2月6日(火) 8:33 Tim Starling :

On 2/2/24 20:27, youkidearitai wrote:

I see. I'll change mb_ucfirst using titlecase.

Per my comments a month ago on the GitHub issue , I think it is much better to 
use title case for mb_ucfirst() than to use upper case, since conversion of the 
first character to upper case has the effect of corrupting text in the Georgian 
script, and initial lower-case ligatures are converted to a form which appears 
like two upper case letters. So I'm pleased to see this change to the PR.

I would appreciate it if the RFC could also be updated to include this detail, 
since my vote depends on whether title case or upper case will be used.

-- Tim Starling

Hi, Tim

Thank you for your comment.
I modified to "uses unicode case title" in an RFC.

Regards
Yuya



Help me out here, but doesn't changing what is actually proposed in an 
RFC **after** the vote has started invalidate the vote ?


Shouldn't the vote be closed/withdrawn and restarted in that case ?

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

[Larry Garfield]

On Tue, Feb 6, 2024, at 2:28 PM, Saki Takamachi wrote:
> Hi Larry,
>
>> I like this proposal.  It's a good incremental improvement to PDO.  I also 
>> agree with rollbackTo(), to avoid confusion.
>
> Thank you, I'm glad to receive your positive feedback.
>
> It is very difficult to implement these in pdo_odbc because the odbc 
> API does not support savepoint.
>
> However, since odbc itself is quite old, it may be a good idea to make 
> only pdo_odbc incompatible with the savepoint method.

There's been discussion recently about how to deal with incompatibilities 
between different PDO drivers, especially now that we can have subclasses per 
driver.  That may be the way to deal with it.  I don't have a major opinion on 
the approach, other than all incompatibilities should be handled in a 
consistent way.

--Larry Garfield

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

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Larry Garfield]

On Tue, Feb 6, 2024, at 4:13 PM, Григорий Senior PHP / Разработчик Web wrote:
> Btw, i agree about Javascript, but on a low level it produces the most
> clean code, because there's no types and rules. All types moved to
> TypeScript's client side compiler.
>
> JS 15 years ago ACCIDENTALLY created a pipeline. Named it "Promise". We
> spent years after to understand that while (true) and then/catch should be
> different patterns.

I assume much of this thread is a language-barrier issue, which is making it 
more hostile than it needs to be.  So let me try and expand a bit, because I am 
actually quite sympathetic to the OP's request, though not the way it's being 
made.

First of all, please don't top post.  It is considered rude on this list.  
GMail makes it a bit annoying to bottom post but it can be done.  Please do so.

Second, there's considerable prior art and discussion on the topic of error 
handling and exceptions.  In particular, I recommend this excellent article by 
Joe Duffy:

https://joeduffyblog.com/2016/02/07/the-error-model/

And this one from me:

https://peakd.com/hive-168588/@crell/much-ado-about-null

Yes, they're long, but error handling is a topic that requires more than casual 
thought.

To summarize the articles for the short of time:

* Exceptions in many languages (including PHP) are very expensive. The stack 
trace is one of the most expensive things PHP does.  This is one of the reasons 
why exceptions are terrible for flow control.
* Unchecked exceptions (where a function doesn't define what it can throw) are 
a great way to break your application in exciting and unpredictable ways.  
(This is the other reason exceptions are terrible for flow control.)
* Many people find checked exceptions cumbersome, even though they are better 
(for reasons Duffy goes into).  This is due mostly to bad design of checked 
exceptions in JVM languages.
* The real problem is that we have a channel for a success case (return value), 
a channel for catastrophic failure (exceptions), but no channel for mundane 
errors (things a responsible developer should expect and know how to handle 
gracefully).  So those get shoved into one or the other, usually an exception.

The need is for a "mundane error" channel.  I agree with this.  Different 
languages handle it in different ways.

* Go has multi-returns.
* Rust has the Result type (which is an Either monad), and an auto-propagation 
operator (?).
* PHP has union types (though that's not a deliberate design, just an emergent 
one).

One of the key differences between different approaches is whether they force 
you to handle error cases (Result type) or let you ignore errors and assume a 
happy path (Go, PHP), letting an unhappy path just explode later on.  Whether 
the language should force you to think about unhappy paths is a complex and 
subjective question that I won't delve into now beyond saying that there's 
valid arguments and use cases for both designs.

As noted in the article above, I've started using enums and union type returns 
a lot for error handling and it's pretty nice, all things considered.  That 
works today in all supported PHP verisons (8.1+).  That said, it's not perfect, 
in part because it's not standardized and there's no really good language-level 
automation around it.

If we had generics and ADTs, building a Rust-like Result type would be super 
easy, and I'd suggest we include one in the stdlib for consistency.  We'll 
probably get ADTs eventually, but generics are not something I'd bank on, so 
that is out.

HOWEVER, and this is where the important part lies, an open, lightweight, 
checked exception system is isomorphic to a Result object.  It's just 
unwrapped.  Compare these hypotheticals:

class DivByZero {}
(this could also be an enum case, but being generic for now.)

function divide(float $a, float $b): Result
{
if ($b === 0) return new Result::Err(new DivByZero());
   return new Result::OK($a/$b);
}

$result = divide(5, 0);
$x = match ($result) {
  is Result::OK($x) => $x,
  is Result::Err => // Do some kind of error handling.
}

vs.

function divide(float $a, float $b): int raises DivByZero
{
if ($b === 0) raise new DivByZero();
   return new $a/$b;
}

try {
  $result = divide(5, 0);
  // Do stuff with $result, knowing it is valid.
} catch (DivByZero) {
  // Do some kind of error handling.
}

These two samples *are logically identical*, and even have mostly the same 
performance characteristics, and both expose useful data to static analyzers.  
They're just spelled differently.  The advantage of the second is that it could 
be implemented without generics.  (ADTs would be an optional nice-to-have.)  
And if the caller doesn't handle DivByZero, it would try to pass it up to its 
caller, but being checked it would require the caller to also declare that it 
can raise DivByZero.

The second option could also be improved by other syntactic sugar to make it 
easier to work with, like Rust has.  For example:

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Григорий Senior PHP / Разработчик Web]

Btw, i agree about Javascript, but on a low level it produces the most
clean code, because there's no types and rules. All types moved to
TypeScript's client side compiler.

JS 15 years ago ACCIDENTALLY created a pipeline. Named it "Promise". We
spent years after to understand that while (true) and then/catch should be
different patterns.

вт, 6 февр. 2024 г. в 19:08, Григорий Senior PHP / Разработчик Web <
6562...@gmail.com>:

> My function seems like this:
>
> ```
> _error_bag_error(error) {
>   if (stack.errorBag) {
>  stack.errorBag.add(error);
>   }
> }
> ```
>
> It does nothing if i didn't initialize the error bag manually.
> I should call _error_bag() inside the current function to create one in
> the stack, or _error_bag_push() (and then _error_bag_pop()) outside the
> function to collect children.
>
> Doctrine's main problem is the dreadnought that throws low level
> exceptions and forces developers to spend weeks to understand "wow, that's
> the way it should be". Funny but painful. For one small benefit - reducing
> the count of queries by unique insertions/deletions, maybe 10% of queries
> are removed.
>
> вт, 6 февр. 2024 г. в 18:54, Arvids Godjuks :
>
>> JavaScript is JavaScript - it's not a good role model to look at. If
>> anything, JavaScript is a collection of things of how not to design a
>> language :)
>>
>> What you are looking for is Golang.
>>
>> The level of changes you are proposing require it to go thriugh an RFC
>> process, have 2/3rds of voters to agree to it. Tland that is after a
>> feasibility study is even done - engine might not even allow to implement
>> such thi g and require exte sive modifications for a thing that should be
>> done on application level to begin with.
>>
>> And memory usage is one of the biggest points against it - engine
>> allowing to store I side it arbitrary data that is logged by application on
>> a per-request level is just a bad idea. People will shove megabytes of logs
>> into it in a loop and them file reports "why is php using 2 GB of RAM?" -
>> this is literally a daily question you get woth relation to Doctrine when
>> people try to run bulk operations, do not disable trace logger and them run
>> into the memory limit.
>>
>>
>> What you are proposing is a footgun at it's finest and PHP has a rich
>> history of those and we have learned from the experience as a community.
>> Things like this are left to the userland. There are many libraries that
>> help handle this.
>>
>> On Tue, Feb 6, 2024, 17:35 Григорий Senior PHP / Разработчик Web <
>> 6562...@gmail.com> wrote:
>>
>>> Javascript is closer to.
>>>
>>> It allows you to throw anything, but it is still the throw statement,
>>> keeping in the mind the async nature of js - memory and processor stuff
>>> is
>>> shared by the time.
>>>
>>> JS seniors usually hate those guys who throw anything except language
>>> Error
>>> class because they skipped the mandatory level of programming - OOP. They
>>> are now taking fun from it. We're tired of OOP for now. Once you work
>>> with
>>> batches/queue/bulks you need pipelines and chaining, and there's a throw
>>> works only to stop any certain tasks and almost immediately catch the
>>> next
>>> line. So `throw` is required to be safe-shield, but solves not enough
>>> count
>>> of cases.
>>>
>>> Old, maybe 10 years ago, Fowler's article about "errors is not an
>>> exception". He explained why, but recommend to implement own error bag. I
>>> tried few times implement own error bag on production ready code. And
>>> this
>>> is the hell of rewriting full nesting tree and carrying that return
>>> statement to upper level again and again, then you start to get confused,
>>> then you rewrite all return to objects with properties/getters/setters,
>>> then you understand your PHPStorm started to lag because of 70 uses in
>>> class... Better to use global error bag stack that you can enable or
>>> disable for your needs outside function ("in controller", GRASP) or
>>> inside
>>> function directly like old good times $errors[] and if ($errors) { return
>>> null; }
>>>
>>>
>>> вт, 6 февр. 2024 г. в 18:23, Alex Wells :
>>>
>>> > On Tue, Feb 6, 2024 at 3:58 PM Григорий Senior PHP / Разработчик Web <
>>> > 6562...@gmail.com> wrote:
>>> >
>>> >> - add non-breakable interface and language construct `raise` to
>>> "throw"
>>> >> error without collecting trace
>>> >> - that error could be any scalar or object, or you can implement new
>>> >> interface for them, keeping that is nested and taggable array
>>> >> - this `raise` could be catched same way as \Throwable allowing log it
>>> >> anywhere you need or re-`raise` again
>>> >> - `raise` statement won't start to collapse/break code, so it could be
>>> >> skipped without affecting application
>>> >>
>>> >
>>> > Is there an existing language that does that, having both exceptions
>>> and
>>> > these silent raise statements?
>>> >
>>>
>>>
>>> --
>>> +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Григорий Senior PHP / Разработчик Web]

My function seems like this:

```
_error_bag_error(error) {
  if (stack.errorBag) {
 stack.errorBag.add(error);
  }
}
```

It does nothing if i didn't initialize the error bag manually.
I should call _error_bag() inside the current function to create one in the
stack, or _error_bag_push() (and then _error_bag_pop()) outside the
function to collect children.

Doctrine's main problem is the dreadnought that throws low level exceptions
and forces developers to spend weeks to understand "wow, that's the way it
should be". Funny but painful. For one small benefit - reducing the count
of queries by unique insertions/deletions, maybe 10% of queries are removed.

вт, 6 февр. 2024 г. в 18:54, Arvids Godjuks :

> JavaScript is JavaScript - it's not a good role model to look at. If
> anything, JavaScript is a collection of things of how not to design a
> language :)
>
> What you are looking for is Golang.
>
> The level of changes you are proposing require it to go thriugh an RFC
> process, have 2/3rds of voters to agree to it. Tland that is after a
> feasibility study is even done - engine might not even allow to implement
> such thi g and require exte sive modifications for a thing that should be
> done on application level to begin with.
>
> And memory usage is one of the biggest points against it - engine allowing
> to store I side it arbitrary data that is logged by application on a
> per-request level is just a bad idea. People will shove megabytes of logs
> into it in a loop and them file reports "why is php using 2 GB of RAM?" -
> this is literally a daily question you get woth relation to Doctrine when
> people try to run bulk operations, do not disable trace logger and them run
> into the memory limit.
>
>
> What you are proposing is a footgun at it's finest and PHP has a rich
> history of those and we have learned from the experience as a community.
> Things like this are left to the userland. There are many libraries that
> help handle this.
>
> On Tue, Feb 6, 2024, 17:35 Григорий Senior PHP / Разработчик Web <
> 6562...@gmail.com> wrote:
>
>> Javascript is closer to.
>>
>> It allows you to throw anything, but it is still the throw statement,
>> keeping in the mind the async nature of js - memory and processor stuff is
>> shared by the time.
>>
>> JS seniors usually hate those guys who throw anything except language
>> Error
>> class because they skipped the mandatory level of programming - OOP. They
>> are now taking fun from it. We're tired of OOP for now. Once you work with
>> batches/queue/bulks you need pipelines and chaining, and there's a throw
>> works only to stop any certain tasks and almost immediately catch the next
>> line. So `throw` is required to be safe-shield, but solves not enough
>> count
>> of cases.
>>
>> Old, maybe 10 years ago, Fowler's article about "errors is not an
>> exception". He explained why, but recommend to implement own error bag. I
>> tried few times implement own error bag on production ready code. And this
>> is the hell of rewriting full nesting tree and carrying that return
>> statement to upper level again and again, then you start to get confused,
>> then you rewrite all return to objects with properties/getters/setters,
>> then you understand your PHPStorm started to lag because of 70 uses in
>> class... Better to use global error bag stack that you can enable or
>> disable for your needs outside function ("in controller", GRASP) or inside
>> function directly like old good times $errors[] and if ($errors) { return
>> null; }
>>
>>
>> вт, 6 февр. 2024 г. в 18:23, Alex Wells :
>>
>> > On Tue, Feb 6, 2024 at 3:58 PM Григорий Senior PHP / Разработчик Web <
>> > 6562...@gmail.com> wrote:
>> >
>> >> - add non-breakable interface and language construct `raise` to "throw"
>> >> error without collecting trace
>> >> - that error could be any scalar or object, or you can implement new
>> >> interface for them, keeping that is nested and taggable array
>> >> - this `raise` could be catched same way as \Throwable allowing log it
>> >> anywhere you need or re-`raise` again
>> >> - `raise` statement won't start to collapse/break code, so it could be
>> >> skipped without affecting application
>> >>
>> >
>> > Is there an existing language that does that, having both exceptions and
>> > these silent raise statements?
>> >
>>
>>
>> --
>> +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи
>> https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
>> 6562...@gmail.com
>>
>

-- 
+375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи
https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
6562...@gmail.com

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Arvids Godjuks]

JavaScript is JavaScript - it's not a good role model to look at. If
anything, JavaScript is a collection of things of how not to design a
language :)

What you are looking for is Golang.

The level of changes you are proposing require it to go thriugh an RFC
process, have 2/3rds of voters to agree to it. Tland that is after a
feasibility study is even done - engine might not even allow to implement
such thi g and require exte sive modifications for a thing that should be
done on application level to begin with.

And memory usage is one of the biggest points against it - engine allowing
to store I side it arbitrary data that is logged by application on a
per-request level is just a bad idea. People will shove megabytes of logs
into it in a loop and them file reports "why is php using 2 GB of RAM?" -
this is literally a daily question you get woth relation to Doctrine when
people try to run bulk operations, do not disable trace logger and them run
into the memory limit.


What you are proposing is a footgun at it's finest and PHP has a rich
history of those and we have learned from the experience as a community.
Things like this are left to the userland. There are many libraries that
help handle this.

On Tue, Feb 6, 2024, 17:35 Григорий Senior PHP / Разработчик Web <
6562...@gmail.com> wrote:

> Javascript is closer to.
>
> It allows you to throw anything, but it is still the throw statement,
> keeping in the mind the async nature of js - memory and processor stuff is
> shared by the time.
>
> JS seniors usually hate those guys who throw anything except language Error
> class because they skipped the mandatory level of programming - OOP. They
> are now taking fun from it. We're tired of OOP for now. Once you work with
> batches/queue/bulks you need pipelines and chaining, and there's a throw
> works only to stop any certain tasks and almost immediately catch the next
> line. So `throw` is required to be safe-shield, but solves not enough count
> of cases.
>
> Old, maybe 10 years ago, Fowler's article about "errors is not an
> exception". He explained why, but recommend to implement own error bag. I
> tried few times implement own error bag on production ready code. And this
> is the hell of rewriting full nesting tree and carrying that return
> statement to upper level again and again, then you start to get confused,
> then you rewrite all return to objects with properties/getters/setters,
> then you understand your PHPStorm started to lag because of 70 uses in
> class... Better to use global error bag stack that you can enable or
> disable for your needs outside function ("in controller", GRASP) or inside
> function directly like old good times $errors[] and if ($errors) { return
> null; }
>
>
> вт, 6 февр. 2024 г. в 18:23, Alex Wells :
>
> > On Tue, Feb 6, 2024 at 3:58 PM Григорий Senior PHP / Разработчик Web <
> > 6562...@gmail.com> wrote:
> >
> >> - add non-breakable interface and language construct `raise` to "throw"
> >> error without collecting trace
> >> - that error could be any scalar or object, or you can implement new
> >> interface for them, keeping that is nested and taggable array
> >> - this `raise` could be catched same way as \Throwable allowing log it
> >> anywhere you need or re-`raise` again
> >> - `raise` statement won't start to collapse/break code, so it could be
> >> skipped without affecting application
> >>
> >
> > Is there an existing language that does that, having both exceptions and
> > these silent raise statements?
> >
>
>
> --
> +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи
> https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
> 6562...@gmail.com
>

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Григорий Senior PHP / Разработчик Web]

Javascript is closer to.

It allows you to throw anything, but it is still the throw statement,
keeping in the mind the async nature of js - memory and processor stuff is
shared by the time.

JS seniors usually hate those guys who throw anything except language Error
class because they skipped the mandatory level of programming - OOP. They
are now taking fun from it. We're tired of OOP for now. Once you work with
batches/queue/bulks you need pipelines and chaining, and there's a throw
works only to stop any certain tasks and almost immediately catch the next
line. So `throw` is required to be safe-shield, but solves not enough count
of cases.

Old, maybe 10 years ago, Fowler's article about "errors is not an
exception". He explained why, but recommend to implement own error bag. I
tried few times implement own error bag on production ready code. And this
is the hell of rewriting full nesting tree and carrying that return
statement to upper level again and again, then you start to get confused,
then you rewrite all return to objects with properties/getters/setters,
then you understand your PHPStorm started to lag because of 70 uses in
class... Better to use global error bag stack that you can enable or
disable for your needs outside function ("in controller", GRASP) or inside
function directly like old good times $errors[] and if ($errors) { return
null; }


вт, 6 февр. 2024 г. в 18:23, Alex Wells :

> On Tue, Feb 6, 2024 at 3:58 PM Григорий Senior PHP / Разработчик Web <
> 6562...@gmail.com> wrote:
>
>> - add non-breakable interface and language construct `raise` to "throw"
>> error without collecting trace
>> - that error could be any scalar or object, or you can implement new
>> interface for them, keeping that is nested and taggable array
>> - this `raise` could be catched same way as \Throwable allowing log it
>> anywhere you need or re-`raise` again
>> - `raise` statement won't start to collapse/break code, so it could be
>> skipped without affecting application
>>
>
> Is there an existing language that does that, having both exceptions and
> these silent raise statements?
>


-- 
+375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи
https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
6562...@gmail.com

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Robert Landers]

On Tue, Feb 6, 2024 at 4:26 PM Григорий Senior PHP / Разработчик Web
<6562...@gmail.com> wrote:
>
> Short answer is yes. Glad to see that personally adapted answer.
>
> That's why in the relevant github issue i show how to collect ONLY if you
> need.
> If you initialize the error bag - it collects, if not - it skips. T
>
> So the `try/catch` statement outside means you initialized, also a special
> decorator or additional command could initiate the raise collector right in
> the function !
>
> You collect only the cases you want to collect. That's the difference.
>
>
>
> Tue, Feb 6 2024 at 18:20, Alexander Pravdin :
>
> > On Wed, Feb 7, 2024 at 12:00 AM Григорий Senior PHP / Разработчик Web
> > <6562...@gmail.com> wrote:
> > >
> > > Sending you private emails made because "answer" button in Gmail selects
> > > only you to receive.
> > > Sending you private emails that don't even read signs to me you don't
> > need
> > > my answers and have no benefits from reading. But you deny, dont even
> > want
> > > to understand. And notify all subscribers about what you don't want to
> > > understand, and about my mistakes.
> > >
> > > ```
> > > It's business-level, capitalism, if you want so, issue. And it sounds
> > like
> > > "we won't pay you for your mistakes".
> > >
> > > There's no magic pill that accidentally forces business to understand you
> > > now need errors collection and it needs at least two more days for
> > > "design-level" refactoring without business benefit. Also no magic pills
> > to
> > > force the business owner to give you that 2 days before you face that
> > > requirement (you know, deadlines stuff).
> > >
> > > Refactoring should be reduced by time as much as possible otherwise you
> > > feel more stress on your job. I have no goal to convince you that this is
> > > necessary, I solved this problem for myself. But at the language level it
> > > can be solved more conveniently and better, and you will also benefit
> > from
> > > this.
> > >
> > > All languages work as a stack. So errors could be collected as a stack on
> > > language level. Directly in place you need that stack instead of
> > > everywhere. Also forcing to close applications is safe-shield, instead of
> > > validation errors that could be found anywhere. PHP devs in most even
> > > imagined a solution that "you have to do validation as much earlier as
> > you
> > > can". But... remote api responses still become from inside to outside,
> > > remote api requirements that accidentally arrive still become once your
> > > code is ready, and unpredictable.
> > >
> > > That simple enhancement allows you to implement error collection and
> > > dont touch your methods and signatures. Nice and easy. Or you can believe
> > > in `truth` and deny ideas because it does not correlate with your
> > > principles.
> >
> > Hey friend, easy :)
> >
> > You was correctly pointed out that this is an application-level issue,
> > not a language one. It is your responsibility to collect anything you
> > want and deal with the business when it puts some requirements. Did
> > you ever experience out-of-memory issues because something in your
> > application is collecting some stuff and don't dispose it? Did you
> > ever work with algorithms running iterations over millions of records
> > in PHP? Can you imagine a language-level bomb if PHP will collect
> > anything in its own memory in every iteration of this kind and not
> > dispose it during the whole request?
> >
> > You don't need to reply to me, just take a deep breath and think about
> > it. I believe this kind of discussions is an off-topic in this mailing
> > list.
> >
> >
> > --
> > Best, Alexander.
> >
> >
> > > ```
> > >
> > > вт, 6 февр. 2024 г. в 17:56, Arvids Godjuks :
> > >
> > > >
> > > >
> > > > On Tue, 6 Feb 2024 at 16:39, Arvids Godjuks 
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Tue, 6 Feb 2024 at 15:58, Григорий Senior PHP / Разработчик Web <
> > > >> 6562...@gmail.com> wrote:
> > > >>
> > > >>> Hello, please discuss about error collecting implementation in next
> > PHP
> > > >>> releases
> > > >>>
> > > >>> Exceptions have common differences that restrict using them to
> > collect
> > > >>> errors
> > > >>> 1. Timeloss (trace collection) on call new() on any class that
> > implements
> > > >>> \Throwable
> > > >>> 2. To collect errors and return it to the upper level you have to
> > change
> > > >>> the return signature, so most of the time rewrite the full tree and
> > > >>> change
> > > >>> all signatures, that's inapplicable and causes more refactor time
> > without
> > > >>> any benefits
> > > >>> 3. Exceptions will break code, so you need to catch them as much
> > closely
> > > >>> as
> > > >>> possible to place you throw it (additional refactoring)
> > > >>>
> > > >>> What I want from this feature:
> > > >>> - while I am writing the api, I need not only "log" the errors, but
> > be
> > > >>> able
> > > >>> to send all script errors to json output, including 

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Alex Wells]

On Tue, Feb 6, 2024 at 5:26 PM Григорий Senior PHP / Разработчик Web <
6562...@gmail.com> wrote:

> Short answer is yes. Glad to see that personally adapted answer.
>

 What are those languages specifically?

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Alex Wells]

On Tue, Feb 6, 2024 at 3:58 PM Григорий Senior PHP / Разработчик Web <
6562...@gmail.com> wrote:

> - add non-breakable interface and language construct `raise` to "throw"
> error without collecting trace
> - that error could be any scalar or object, or you can implement new
> interface for them, keeping that is nested and taggable array
> - this `raise` could be catched same way as \Throwable allowing log it
> anywhere you need or re-`raise` again
> - `raise` statement won't start to collapse/break code, so it could be
> skipped without affecting application
>

Is there an existing language that does that, having both exceptions and
these silent raise statements?

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Григорий Senior PHP / Разработчик Web]

Short answer is yes. Glad to see that personally adapted answer.

That's why in the relevant github issue i show how to collect ONLY if you
need.
If you initialize the error bag - it collects, if not - it skips. T

So the `try/catch` statement outside means you initialized, also a special
decorator or additional command could initiate the raise collector right in
the function !

You collect only the cases you want to collect. That's the difference.



вт, 6 февр. 2024 г. в 18:20, Alexander Pravdin :

> On Wed, Feb 7, 2024 at 12:00 AM Григорий Senior PHP / Разработчик Web
> <6562...@gmail.com> wrote:
> >
> > Sending you private emails made because "answer" button in Gmail selects
> > only you to receive.
> > Sending you private emails that don't even read signs to me you don't
> need
> > my answers and have no benefits from reading. But you deny, dont even
> want
> > to understand. And notify all subscribers about what you don't want to
> > understand, and about my mistakes.
> >
> > ```
> > It's business-level, capitalism, if you want so, issue. And it sounds
> like
> > "we won't pay you for your mistakes".
> >
> > There's no magic pill that accidentally forces business to understand you
> > now need errors collection and it needs at least two more days for
> > "design-level" refactoring without business benefit. Also no magic pills
> to
> > force the business owner to give you that 2 days before you face that
> > requirement (you know, deadlines stuff).
> >
> > Refactoring should be reduced by time as much as possible otherwise you
> > feel more stress on your job. I have no goal to convince you that this is
> > necessary, I solved this problem for myself. But at the language level it
> > can be solved more conveniently and better, and you will also benefit
> from
> > this.
> >
> > All languages work as a stack. So errors could be collected as a stack on
> > language level. Directly in place you need that stack instead of
> > everywhere. Also forcing to close applications is safe-shield, instead of
> > validation errors that could be found anywhere. PHP devs in most even
> > imagined a solution that "you have to do validation as much earlier as
> you
> > can". But... remote api responses still become from inside to outside,
> > remote api requirements that accidentally arrive still become once your
> > code is ready, and unpredictable.
> >
> > That simple enhancement allows you to implement error collection and
> > dont touch your methods and signatures. Nice and easy. Or you can believe
> > in `truth` and deny ideas because it does not correlate with your
> > principles.
>
> Hey friend, easy :)
>
> You was correctly pointed out that this is an application-level issue,
> not a language one. It is your responsibility to collect anything you
> want and deal with the business when it puts some requirements. Did
> you ever experience out-of-memory issues because something in your
> application is collecting some stuff and don't dispose it? Did you
> ever work with algorithms running iterations over millions of records
> in PHP? Can you imagine a language-level bomb if PHP will collect
> anything in its own memory in every iteration of this kind and not
> dispose it during the whole request?
>
> You don't need to reply to me, just take a deep breath and think about
> it. I believe this kind of discussions is an off-topic in this mailing
> list.
>
>
> --
> Best, Alexander.
>
>
> > ```
> >
> > вт, 6 февр. 2024 г. в 17:56, Arvids Godjuks :
> >
> > >
> > >
> > > On Tue, 6 Feb 2024 at 16:39, Arvids Godjuks 
> > > wrote:
> > >
> > >>
> > >>
> > >> On Tue, 6 Feb 2024 at 15:58, Григорий Senior PHP / Разработчик Web <
> > >> 6562...@gmail.com> wrote:
> > >>
> > >>> Hello, please discuss about error collecting implementation in next
> PHP
> > >>> releases
> > >>>
> > >>> Exceptions have common differences that restrict using them to
> collect
> > >>> errors
> > >>> 1. Timeloss (trace collection) on call new() on any class that
> implements
> > >>> \Throwable
> > >>> 2. To collect errors and return it to the upper level you have to
> change
> > >>> the return signature, so most of the time rewrite the full tree and
> > >>> change
> > >>> all signatures, that's inapplicable and causes more refactor time
> without
> > >>> any benefits
> > >>> 3. Exceptions will break code, so you need to catch them as much
> closely
> > >>> as
> > >>> possible to place you throw it (additional refactoring)
> > >>>
> > >>> What I want from this feature:
> > >>> - while I am writing the api, I need not only "log" the errors, but
> be
> > >>> able
> > >>> to send all script errors to json output, including warnings,
> errors, and
> > >>> deep nested. It will reduce the time of debugging, otherwise i have
> to
> > >>> download log files from server or configure external system like
> sentry
> > >>> that collects all errors by groups/chains
> > >>>
> > >>> Suggested solution:
> > >>> - add non-breakable interface and language construct `raise` 

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Alexander Pravdin]

On Wed, Feb 7, 2024 at 12:00 AM Григорий Senior PHP / Разработчик Web
<6562...@gmail.com> wrote:
>
> Sending you private emails made because "answer" button in Gmail selects
> only you to receive.
> Sending you private emails that don't even read signs to me you don't need
> my answers and have no benefits from reading. But you deny, dont even want
> to understand. And notify all subscribers about what you don't want to
> understand, and about my mistakes.
>
> ```
> It's business-level, capitalism, if you want so, issue. And it sounds like
> "we won't pay you for your mistakes".
>
> There's no magic pill that accidentally forces business to understand you
> now need errors collection and it needs at least two more days for
> "design-level" refactoring without business benefit. Also no magic pills to
> force the business owner to give you that 2 days before you face that
> requirement (you know, deadlines stuff).
>
> Refactoring should be reduced by time as much as possible otherwise you
> feel more stress on your job. I have no goal to convince you that this is
> necessary, I solved this problem for myself. But at the language level it
> can be solved more conveniently and better, and you will also benefit from
> this.
>
> All languages work as a stack. So errors could be collected as a stack on
> language level. Directly in place you need that stack instead of
> everywhere. Also forcing to close applications is safe-shield, instead of
> validation errors that could be found anywhere. PHP devs in most even
> imagined a solution that "you have to do validation as much earlier as you
> can". But... remote api responses still become from inside to outside,
> remote api requirements that accidentally arrive still become once your
> code is ready, and unpredictable.
>
> That simple enhancement allows you to implement error collection and
> dont touch your methods and signatures. Nice and easy. Or you can believe
> in `truth` and deny ideas because it does not correlate with your
> principles.

Hey friend, easy :)

You was correctly pointed out that this is an application-level issue,
not a language one. It is your responsibility to collect anything you
want and deal with the business when it puts some requirements. Did
you ever experience out-of-memory issues because something in your
application is collecting some stuff and don't dispose it? Did you
ever work with algorithms running iterations over millions of records
in PHP? Can you imagine a language-level bomb if PHP will collect
anything in its own memory in every iteration of this kind and not
dispose it during the whole request?

You don't need to reply to me, just take a deep breath and think about
it. I believe this kind of discussions is an off-topic in this mailing
list.


-- 
Best, Alexander.


> ```
>
> вт, 6 февр. 2024 г. в 17:56, Arvids Godjuks :
>
> >
> >
> > On Tue, 6 Feb 2024 at 16:39, Arvids Godjuks 
> > wrote:
> >
> >>
> >>
> >> On Tue, 6 Feb 2024 at 15:58, Григорий Senior PHP / Разработчик Web <
> >> 6562...@gmail.com> wrote:
> >>
> >>> Hello, please discuss about error collecting implementation in next PHP
> >>> releases
> >>>
> >>> Exceptions have common differences that restrict using them to collect
> >>> errors
> >>> 1. Timeloss (trace collection) on call new() on any class that implements
> >>> \Throwable
> >>> 2. To collect errors and return it to the upper level you have to change
> >>> the return signature, so most of the time rewrite the full tree and
> >>> change
> >>> all signatures, that's inapplicable and causes more refactor time without
> >>> any benefits
> >>> 3. Exceptions will break code, so you need to catch them as much closely
> >>> as
> >>> possible to place you throw it (additional refactoring)
> >>>
> >>> What I want from this feature:
> >>> - while I am writing the api, I need not only "log" the errors, but be
> >>> able
> >>> to send all script errors to json output, including warnings, errors, and
> >>> deep nested. It will reduce the time of debugging, otherwise i have to
> >>> download log files from server or configure external system like sentry
> >>> that collects all errors by groups/chains
> >>>
> >>> Suggested solution:
> >>> - add non-breakable interface and language construct `raise` to "throw"
> >>> error without collecting trace
> >>> - that error could be any scalar or object, or you can implement new
> >>> interface for them, keeping that is nested and taggable array
> >>> - this `raise` could be catched same way as \Throwable allowing log it
> >>> anywhere you need or re-`raise` again
> >>> - `raise` statement won't start to collapse/break code, so it could be
> >>> skipped without affecting application
> >>>
> >>> Current solution:
> >>> a) 2 classes - ErrorBag/ErrorBagStack.
> >>>
> >>> b) native functions like _error()/_warning() that stores errors to the
> >>> current ErrorBag if it exists.
> >>>
> >>> c) ErrorBag exists only if you initialize it:
> >>> - from the upper level (you need to 

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Григорий Senior PHP / Разработчик Web]

Sending you private emails made because "answer" button in Gmail selects
only you to receive.
Sending you private emails that don't even read signs to me you don't need
my answers and have no benefits from reading. But you deny, dont even want
to understand. And notify all subscribers about what you don't want to
understand, and about my mistakes.

```
It's business-level, capitalism, if you want so, issue. And it sounds like
"we won't pay you for your mistakes".

There's no magic pill that accidentally forces business to understand you
now need errors collection and it needs at least two more days for
"design-level" refactoring without business benefit. Also no magic pills to
force the business owner to give you that 2 days before you face that
requirement (you know, deadlines stuff).

Refactoring should be reduced by time as much as possible otherwise you
feel more stress on your job. I have no goal to convince you that this is
necessary, I solved this problem for myself. But at the language level it
can be solved more conveniently and better, and you will also benefit from
this.

All languages work as a stack. So errors could be collected as a stack on
language level. Directly in place you need that stack instead of
everywhere. Also forcing to close applications is safe-shield, instead of
validation errors that could be found anywhere. PHP devs in most even
imagined a solution that "you have to do validation as much earlier as you
can". But... remote api responses still become from inside to outside,
remote api requirements that accidentally arrive still become once your
code is ready, and unpredictable.

That simple enhancement allows you to implement error collection and
dont touch your methods and signatures. Nice and easy. Or you can believe
in `truth` and deny ideas because it does not correlate with your
principles.
```

вт, 6 февр. 2024 г. в 17:56, Arvids Godjuks :

>
>
> On Tue, 6 Feb 2024 at 16:39, Arvids Godjuks 
> wrote:
>
>>
>>
>> On Tue, 6 Feb 2024 at 15:58, Григорий Senior PHP / Разработчик Web <
>> 6562...@gmail.com> wrote:
>>
>>> Hello, please discuss about error collecting implementation in next PHP
>>> releases
>>>
>>> Exceptions have common differences that restrict using them to collect
>>> errors
>>> 1. Timeloss (trace collection) on call new() on any class that implements
>>> \Throwable
>>> 2. To collect errors and return it to the upper level you have to change
>>> the return signature, so most of the time rewrite the full tree and
>>> change
>>> all signatures, that's inapplicable and causes more refactor time without
>>> any benefits
>>> 3. Exceptions will break code, so you need to catch them as much closely
>>> as
>>> possible to place you throw it (additional refactoring)
>>>
>>> What I want from this feature:
>>> - while I am writing the api, I need not only "log" the errors, but be
>>> able
>>> to send all script errors to json output, including warnings, errors, and
>>> deep nested. It will reduce the time of debugging, otherwise i have to
>>> download log files from server or configure external system like sentry
>>> that collects all errors by groups/chains
>>>
>>> Suggested solution:
>>> - add non-breakable interface and language construct `raise` to "throw"
>>> error without collecting trace
>>> - that error could be any scalar or object, or you can implement new
>>> interface for them, keeping that is nested and taggable array
>>> - this `raise` could be catched same way as \Throwable allowing log it
>>> anywhere you need or re-`raise` again
>>> - `raise` statement won't start to collapse/break code, so it could be
>>> skipped without affecting application
>>>
>>> Current solution:
>>> a) 2 classes - ErrorBag/ErrorBagStack.
>>>
>>> b) native functions like _error()/_warning() that stores errors to the
>>> current ErrorBag if it exists.
>>>
>>> c) ErrorBag exists only if you initialize it:
>>> - from the upper level (you need to collect)
>>> - directly inside a function (you need to decide return/continue
>>> depending
>>> on its emptiness)
>>> - otherwise _error()/_warning() does nothing
>>>
>>> d) once you "catch" results of _error()/_warning() you often need it to
>>> merge the result to the current errorbag, mark it with a nesting group or
>>> with the tag. Nesting group is required once you debug code (you will see
>>> the log), tags will needed once you want to copy results from one bag to
>>> another (closest example - reduce queue with unique function, do action,
>>> then work with initial data)
>>>
>>> e) useful feature is merge_as_warning($errorBag) - to prevent the current
>>> error bag to return `true` on call ->hasErrors(). Errors are related to
>>> low
>>> level function, and possibly you already do actions that allow you just
>>> store them.
>>>
>>> f) searching inside the error bag by nesting sequence, or by tag, or by
>>> error type. Error type helps the same as try/catch, tag helps if you want
>>> to save errors to several destinations without memory 

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Arvids Godjuks]

On Tue, 6 Feb 2024 at 16:39, Arvids Godjuks 
wrote:

>
>
> On Tue, 6 Feb 2024 at 15:58, Григорий Senior PHP / Разработчик Web <
> 6562...@gmail.com> wrote:
>
>> Hello, please discuss about error collecting implementation in next PHP
>> releases
>>
>> Exceptions have common differences that restrict using them to collect
>> errors
>> 1. Timeloss (trace collection) on call new() on any class that implements
>> \Throwable
>> 2. To collect errors and return it to the upper level you have to change
>> the return signature, so most of the time rewrite the full tree and change
>> all signatures, that's inapplicable and causes more refactor time without
>> any benefits
>> 3. Exceptions will break code, so you need to catch them as much closely
>> as
>> possible to place you throw it (additional refactoring)
>>
>> What I want from this feature:
>> - while I am writing the api, I need not only "log" the errors, but be
>> able
>> to send all script errors to json output, including warnings, errors, and
>> deep nested. It will reduce the time of debugging, otherwise i have to
>> download log files from server or configure external system like sentry
>> that collects all errors by groups/chains
>>
>> Suggested solution:
>> - add non-breakable interface and language construct `raise` to "throw"
>> error without collecting trace
>> - that error could be any scalar or object, or you can implement new
>> interface for them, keeping that is nested and taggable array
>> - this `raise` could be catched same way as \Throwable allowing log it
>> anywhere you need or re-`raise` again
>> - `raise` statement won't start to collapse/break code, so it could be
>> skipped without affecting application
>>
>> Current solution:
>> a) 2 classes - ErrorBag/ErrorBagStack.
>>
>> b) native functions like _error()/_warning() that stores errors to the
>> current ErrorBag if it exists.
>>
>> c) ErrorBag exists only if you initialize it:
>> - from the upper level (you need to collect)
>> - directly inside a function (you need to decide return/continue depending
>> on its emptiness)
>> - otherwise _error()/_warning() does nothing
>>
>> d) once you "catch" results of _error()/_warning() you often need it to
>> merge the result to the current errorbag, mark it with a nesting group or
>> with the tag. Nesting group is required once you debug code (you will see
>> the log), tags will needed once you want to copy results from one bag to
>> another (closest example - reduce queue with unique function, do action,
>> then work with initial data)
>>
>> e) useful feature is merge_as_warning($errorBag) - to prevent the current
>> error bag to return `true` on call ->hasErrors(). Errors are related to
>> low
>> level function, and possibly you already do actions that allow you just
>> store them.
>>
>> f) searching inside the error bag by nesting sequence, or by tag, or by
>> error type. Error type helps the same as try/catch, tag helps if you want
>> to save errors to several destinations without memory losses, and nesting
>> will help most of the time in debugging.
>>
>> Thanks for your attention.
>>
>> --
>> +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи
>> https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
>> 6562...@gmail.com
>>
>
> Hello,
>
> This is an application design-level issue, not a language issue.
> All you need to do is implement a collector on the logger you use that
> will store the info you want and let you ask for that info just before you
> push data into the JSON encoder you use from that logger collector. It's as
> simple as that, you don't even need to change your existing code if it
> already logs the information.
>
> --
>
> Arvīds Godjuks
> +371 26 851 664
> arvids.godj...@gmail.com
> Telegram: @psihius https://t.me/psihius
>

Sending me multiple emails in private with rants is not a behaviour that's
encouraged on this list. Please read the
https://wiki.php.net/email_etiquette_for_people_new_to_php_internals
-- 

Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Arvids Godjuks]

On Tue, 6 Feb 2024 at 15:58, Григорий Senior PHP / Разработчик Web <
6562...@gmail.com> wrote:

> Hello, please discuss about error collecting implementation in next PHP
> releases
>
> Exceptions have common differences that restrict using them to collect
> errors
> 1. Timeloss (trace collection) on call new() on any class that implements
> \Throwable
> 2. To collect errors and return it to the upper level you have to change
> the return signature, so most of the time rewrite the full tree and change
> all signatures, that's inapplicable and causes more refactor time without
> any benefits
> 3. Exceptions will break code, so you need to catch them as much closely as
> possible to place you throw it (additional refactoring)
>
> What I want from this feature:
> - while I am writing the api, I need not only "log" the errors, but be able
> to send all script errors to json output, including warnings, errors, and
> deep nested. It will reduce the time of debugging, otherwise i have to
> download log files from server or configure external system like sentry
> that collects all errors by groups/chains
>
> Suggested solution:
> - add non-breakable interface and language construct `raise` to "throw"
> error without collecting trace
> - that error could be any scalar or object, or you can implement new
> interface for them, keeping that is nested and taggable array
> - this `raise` could be catched same way as \Throwable allowing log it
> anywhere you need or re-`raise` again
> - `raise` statement won't start to collapse/break code, so it could be
> skipped without affecting application
>
> Current solution:
> a) 2 classes - ErrorBag/ErrorBagStack.
>
> b) native functions like _error()/_warning() that stores errors to the
> current ErrorBag if it exists.
>
> c) ErrorBag exists only if you initialize it:
> - from the upper level (you need to collect)
> - directly inside a function (you need to decide return/continue depending
> on its emptiness)
> - otherwise _error()/_warning() does nothing
>
> d) once you "catch" results of _error()/_warning() you often need it to
> merge the result to the current errorbag, mark it with a nesting group or
> with the tag. Nesting group is required once you debug code (you will see
> the log), tags will needed once you want to copy results from one bag to
> another (closest example - reduce queue with unique function, do action,
> then work with initial data)
>
> e) useful feature is merge_as_warning($errorBag) - to prevent the current
> error bag to return `true` on call ->hasErrors(). Errors are related to low
> level function, and possibly you already do actions that allow you just
> store them.
>
> f) searching inside the error bag by nesting sequence, or by tag, or by
> error type. Error type helps the same as try/catch, tag helps if you want
> to save errors to several destinations without memory losses, and nesting
> will help most of the time in debugging.
>
> Thanks for your attention.
>
> --
> +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи
> https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
> 6562...@gmail.com
>

Hello,

This is an application design-level issue, not a language issue.
All you need to do is implement a collector on the logger you use that will
store the info you want and let you ask for that info just before you push
data into the JSON encoder you use from that logger collector. It's as
simple as that, you don't even need to change your existing code if it
already logs the information.

-- 

Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

[Saki Takamachi]

Hi Larry,

> I like this proposal.  It's a good incremental improvement to PDO.  I also 
> agree with rollbackTo(), to avoid confusion.

Thank you, I'm glad to receive your positive feedback.

It is very difficult to implement these in pdo_odbc because the odbc API does 
not support savepoint.

However, since odbc itself is quite old, it may be a good idea to make only 
pdo_odbc incompatible with the savepoint method.

Regards.

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

[PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301

[Григорий Senior PHP / Разработчик Web]

Hello, please discuss about error collecting implementation in next PHP
releases

Exceptions have common differences that restrict using them to collect
errors
1. Timeloss (trace collection) on call new() on any class that implements
\Throwable
2. To collect errors and return it to the upper level you have to change
the return signature, so most of the time rewrite the full tree and change
all signatures, that's inapplicable and causes more refactor time without
any benefits
3. Exceptions will break code, so you need to catch them as much closely as
possible to place you throw it (additional refactoring)

What I want from this feature:
- while I am writing the api, I need not only "log" the errors, but be able
to send all script errors to json output, including warnings, errors, and
deep nested. It will reduce the time of debugging, otherwise i have to
download log files from server or configure external system like sentry
that collects all errors by groups/chains

Suggested solution:
- add non-breakable interface and language construct `raise` to "throw"
error without collecting trace
- that error could be any scalar or object, or you can implement new
interface for them, keeping that is nested and taggable array
- this `raise` could be catched same way as \Throwable allowing log it
anywhere you need or re-`raise` again
- `raise` statement won't start to collapse/break code, so it could be
skipped without affecting application

Current solution:
a) 2 classes - ErrorBag/ErrorBagStack.

b) native functions like _error()/_warning() that stores errors to the
current ErrorBag if it exists.

c) ErrorBag exists only if you initialize it:
- from the upper level (you need to collect)
- directly inside a function (you need to decide return/continue depending
on its emptiness)
- otherwise _error()/_warning() does nothing

d) once you "catch" results of _error()/_warning() you often need it to
merge the result to the current errorbag, mark it with a nesting group or
with the tag. Nesting group is required once you debug code (you will see
the log), tags will needed once you want to copy results from one bag to
another (closest example - reduce queue with unique function, do action,
then work with initial data)

e) useful feature is merge_as_warning($errorBag) - to prevent the current
error bag to return `true` on call ->hasErrors(). Errors are related to low
level function, and possibly you already do actions that allow you just
store them.

f) searching inside the error bag by nesting sequence, or by tag, or by
error type. Error type helps the same as try/catch, tag helps if you want
to save errors to several destinations without memory losses, and nesting
will help most of the time in debugging.

Thanks for your attention.

-- 
+375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи
https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
6562...@gmail.com