Re: [PHP-DEV] [Discussion] Thoughts on casting to null
I don't even know why lambda realization is not the same as in javascript.
```
let action = function () {
console.log('hello');
return 1;
}
let fn1 = () => action();
console.log(fn1()); // calls hello(), returns 1, for me, not a best way,
could be read like "call action() then create function that returns result
of that call"
let fn2 = () => (action());
console.log(fn2()); // calls hello(), returns 1, common, short way
// what's this?
(() => ())(); // could look strange? no, its declaring unnamed function
that does nothing and returns nothing and calls it immediately.
let fn3 = () => { action(); }
console.log(fn3()); // calls hello(), returns undefined, common, short
without return
let fn4 = () => action;
console.log(fn4()); // returns function, very handy for Promises, that
start init function immediate on new call, so it wraps function to "task"
available to call it later somewhere, maybe in another promise
```
Why is the PHP implementation redesigned from scratch instead of using the
idea of the one that works?
ps. Guess, the discussion to change syntax that you cold rewrite with
single line:
```
// > what?
// fn() => $client->ping() ? null : null
// > that
// static function () { $client->ping(); }
```
Ahh, the main problem in fn() is exactly that you don't like `use`
statement So long to write the `use` keyword.
Аnd you prefer the `js` implementation, which automatically uses the
current scope in your callback.
And you need something handy, that is allow create functions:
- with all variables (copy local state)
- with short syntax
- with return modes variety
- with return types and parameter types, if you need it
is more interesting, than talk about error collection that requires
rewriting half of the app
As I remember you say, you work on projects with a million lines of code
and you prefer correctness instead of simplification.
Why do you use short functions then? OOP awaits you.
Create a function that wraps function:
1. one function returns result (client.ping())
2. second one returns null|result (myclass.clientPingOrNull())
3. The third one catches the first one with a try catch to return the
result and return errors (myclass.tryClientPingOrNull())
4. then call that batch of correctness in your callback...
Sorry, couldn't resist myself
Re: [RFC] OOP API for cURL extension
Working with remote servers is a little bit harder than just catching the exception. Just implement OOP stuff gives no benefit except "do not read the docs, but use IDE". Usually count of curl options is so big that it wont help. And also, there's multicurl too. There's batch calling with limit too. There's errors of different types. I mean curl errors on create, curl errors on execute, http errors (network), response errors (invalid data, misformatted data), and api errors, that could be sent even with 200 code. How try/catch will solve? Easy solution, too many discussion points.
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
> I've worked on PHP (and non-PHP) applications with (tens of) millions of lines of code Grats, you're a hero. Now, you're a hero. You can solve the application in your paper notebook. That does not explain why computers should know some correctness and not help you, because you're a hero. I now have the legacy of webinars. There's no webinar archives, only runtime config, blueprints, there's user forms that are only processed in batches by queue, there's 3 levels of nesting in webinars. And there's existing code with wordpress repeaters and such stuff that is working somehow. So my current task is to multiply non-existing webinars to non-existing form submissions and multiply that to wordpress and 3 levels of webinar nesting, and get a solution in a maximum of one week. Suggested solution - "we know the correctness, so you have to tell your manager - you need to completely rewrite existing logic with 1 small methods with exceptions, then catch it everywhere, then write tests, and then debug it at runtime" for the future. That strategy followed by firing out or leaving. It should be fixed in the shortest possible way without rewriting your code. And, it should work fast using massive select/insert to reduce page loading time. If I started to split that 100 repeating fields into simple SOLID methods - it would take a month. I haven't a month, and nobody can give me a new job. So I MUST use non-breaking errors to do it faster. And the community doesn't want to implement handy solutions because they are tired of simple things (because they guess that simple things are always small instead of being plain scripts). Best! Just not enough good words. Thanks for attention.
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
1. Do some benchmark with ```
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
>From that point of view you're absolutely correct. I want to use json_last_error() with global state, but with the ability to manually change the state size to prevent memory overflow. So I suggested it because the count of bad code will grow in arithmetic progression because of the times on the Earth - firing out developers who "know the truth", hiring cheap developers who "just do". You could believe in correctness or help people who need that help. I understand that php spent many years on fast solutions, and btw, I am glad to write code with PHP, even with older versions >5.6 / >7.2, because there's exactly catched balance between "all possible" and "you need to". This `raise` is a case that will be required until somebody changes the business world. But business never changes, in the last 30 years it has become more "predatory" and unscrupulous. Getting back to the error handling problem - still no solution about "exceptions coming to warnings being called in batches/pipes/bulks" and no solution for "each exception could cause time loss on big amounts of incoming data". If you aren't gonna implement `raise` keyword (or other way like that) - at least one thing could be implemented easily - collecting error traces only if it is required, some mark, or flag, if you don't want to implement different interface that won't break/collapse the code, at least by honored SOLID separate responsibility of trace collection and error raising, to reduce timelosses. I mean - allow the developer to throw an error that just stops the code with a message, doing that the fastest way possible. Otherwise, I understand the point, and have nothing to add here.
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
Just because PHPStan is a ready solution for design errors that you can predict. My case is about errors that you detect later, after the design is finished, PHPStan shows you that "all done!". Because it's not \LogicExceptions (types, mappings), it's all \RuntimeExceptions... You have to implement it after the design is done! Also writing code comments for PHPStan accidentally increases time of catching \LogicExceptions that will be autocatched once an exception happens and is reported. This is necessary work, but it increases the estimate; the business does not want to hear long deadlines, and considers you ineffective. But if you say too small, the code will not even pass PHPStan, it will not even pass visual inspection. Therefore, I say some magical things, and then I correct them, for some reason they like this approach better, they are not used to improving until everything works properly, they even push the word into the lexicon - MVP. This means “it doesn’t work well but it works”, it seems normal to them in order to get results faster. Because they will receive bonuses for results, but for bad results you will receive punishment. A closer solution is "get out from the job where business was built that way to ignore complainings". I had worked for 12 years. I've changed a lot of jobs because of that. And any new job is the same. It could be more or less ready to build the same, but they are working on it. It's not a solution either. As a result - "you cant rebuild non-yours successful business that gives you money because you know how things work", you have to fix or lose your rent home. === @Arvids Godjuks I had to work in such companies, and there were 13 projects at the moment. But after some time I realized that nothing depends on the number of projects. All businesses strive to not give away the right to think to their employees. If this happened, it was more an accident than a goal. If they are forced to listen to you, you are considered a problem that they do not yet know how to solve. Now my company has only one project, which they are leading themselves. But business and profit dictate the conditions - at first we do a year very quickly, then we redo it for 3 months, which we will have time, but the amount of legacy is too large, because the pace is insane, and the tasks are becoming more and more difficult. They can't just "wait quietly until you finish." They will ask you when, and will be disappointed if you suddenly suddenly realized that you need to move the deadlines, because there are already 5 new ones behind the current task and they are planned for the quarter. “Rewrite better” is not included in them. Let's stop discussing my personality, I gave a rationale for why languages should preferably help developers, since such a question arose. Because there won’t be fewer situations like mine, but there will be more jobs. And there will be a lot more bad companies, and in the end there will be very bad ones left.
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
Ok, I understand your position. Want explanations about personal behavior - please write by telegram. PHPStan is out the case. SOLID is not a marker of good architecture, it's a marker of idealistic understanding, for me. I already long ago passed that time where I can just say "this code is bad, I am leaving". New rules of business, and then, payments - there's no bad code, there's bad coders. And also "bad coders have to be replaced with AI" (especially once we understand that AI helps only if you already know the answer, they don't solve anything, but use any hype to hit employees). So language should decide - help developers or help businesses. The top of any business = do nothing. That's why business is on the wrong side related to science. Future of any language is predicted not with code beauty, but with payments in the business. Am sure, you're noticed that hard things live longer than easy things. That's a fenomen, that has explanations. Employees prefer easy jobs, businesses prefer hype. Hype requires confusion, controversy. So it's the opposite. Employees want to get more money for the job, businesses want to pay less. Pricing increases once things become more difficult, but I am asking to simplify something. From that position I am asking for bad things. At the same time, I am asking to help most people do their job more easily, to solve more tasks and continue having a job. Just because that `clever` owners will fire out all the people until war clears it out, clears all of us (they survive, because they have money). This is the story of how the strongest and tricky win over the clever and smart. That's why discussions always hit the wall "why we should". You, or language, or community, don't owe anyone anything. Times required from languages make things simpler and at the same time make hype more complex and difficult. One part is needed by employees, the second part must be done for employers. If you make things simpler - it moves tape to employees, but business owners will select more difficult solutions and more legacy, because they dont know `bad` and `good`, they know only hype. Simple things never create hype. That's the mandatory point. Btw, these explanations are very simplified and funny to declare them here.
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
JIT I've had this solved, not only the application, but a way to. Am sharing my experience without labels "bad", "cood", "truth" or "correct", like you did. Your arguments are based on your principles and I don't see in your words any point to discuss, so - use pm or share here secret of error-free code, if you have ideas how to solve "my" application if "you know what is the correct design". I think the people who use labels usually never share their experience.
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
I still don't understand why the problem is signature and moving a simple throw statement to return type, and then rewriting the catch statement to oneline-r. I am completely satisfied with the php way of working with method signatures except non-critical cases: - still no `undefined` type, so some functions have limited functionality with func_num_args() inside - no languages still implement emptiness check on argument types. empty string should always be additionally asserted, like positive-negative numbers, and nan/inf with float stuff (nan/inf is too rarely case) - I'd say generics support but it is fully covered with phpdoc. use argument Generic, mark it as class-string and @template and it works well Try/catch statements don't scare me. I feel the trouble in missing try/catch statements and requirements to check all method call places once you throw a non-critical error just because another way, sorry, necessary way, is too hard for fast implementation. That trouble arrives only when you move from single-task script to multi-task script. The nearest example is SQL, which always works with rows and never returns one value, response is always "list of rows". So the primary method of error handling should be focused on batch processing, but `throw` keyword is very handy for filters, assertions, validators and low level static functions. If you finish your code fully covered with exceptions - once you try to run several times the same with try/catch over method calls - the original action code could have been better by catching some exceptions on its own. However, it is closed to you and now if you want to break it into two parts, you will have to rewrite it completely, because it is completely closed to you and the slightest exception that was not caught in itself (and not in you) will break it entirely, and will not disable part of it. The exception was invented in order to shift the closure of the problem to the next level of developers. However, it is the exception that prevents these developers from changing the source logic of the code that throws it and continuing to perform the action intended in the source code - the exception simply breaks the entire branch (following `encapsulation`). This means it should break only the most primitive functions that can be replaced quickly. This is where the so-called SOLID came from, which forces everything to be broken down into molecules instead of first closing the problem and then deciding whether to break it into parts or leave it that way.
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
As I mentioned above - javascript pipelines (named `Promise` and `Thenable`) are great examples when exceptions are a bad choice. Btw, not "bad", but "choice to stop one step of the chain only". If any step of chain/foreach throws an exception - it will break all code. Should break one step. That's why you throw the immediate catch. And continue to check via if-checking once the result of the pipeline is received. Catching is a good solution for the application core. If some exception pops up at the entrypoint - you could transform the exception to the output. All other cases should be covered without exceptions. If you use exceptions on any occurred error as "truth way" you will meet risk and also timeloss on any misformatted batches/user-inputs. ср, 7 февр. 2024 г. в 18:06, Григорий Senior PHP / Разработчик Web < 6562...@gmail.com>: > Analyzing the problem on a single level operation is incorrect. New code > and simple operations are fully covered with exception/try/catch flow. > > The main point i tried to attract your attention is that if you working in > batches/queues/pipelines you still need errors collection, and if you made > error flow with exceptions - you have to extract validations to separate > classes/dto-s, made return types as objects, try/catching as fast as > possible, and then you will still met errors from remote systems, network > errors, and invalid response parsing that need to be logged as much close > to task registration place. > > So correct analysis - providing an example with at least foreaches/yields > instead of simply calling native functions. In small functions IF > statements are overkill, and even try-catch could be skipped, because the > whole script will fall and that's correct behavior. > > Case is in that the script should continue working while working with > chaining/nesting, and should be able to easily refactor any step to skip > one or more bulk-data rows of each step on any nesting level. > -- +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
Analyzing the problem on a single level operation is incorrect. New code and simple operations are fully covered with exception/try/catch flow. The main point i tried to attract your attention is that if you working in batches/queues/pipelines you still need errors collection, and if you made error flow with exceptions - you have to extract validations to separate classes/dto-s, made return types as objects, try/catching as fast as possible, and then you will still met errors from remote systems, network errors, and invalid response parsing that need to be logged as much close to task registration place. So correct analysis - providing an example with at least foreaches/yields instead of simply calling native functions. In small functions IF statements are overkill, and even try-catch could be skipped, because the whole script will fall and that's correct behavior. Case is in that the script should continue working while working with chaining/nesting, and should be able to easily refactor any step to skip one or more bulk-data rows of each step on any nesting level.
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
Yes, that was the second build of the error bag I presented in the github ticket. First one was a Trait that added an error bag as property in class and returned an array with two results. The trouble was you have to refactor all places you used your function doesn't matter, want you or not. And the last build just collects errors to the global stack of error bags allowing you to stay untouched by the existing code. Of course, if code should start to return null/null-object as result - you have to implement that (refactoring the places where null is inapplicable), but error collection itself won't change existing code then, it works like an observer pattern now. ср, 7 февр. 2024 г. в 13:21, Robert Landers : > On Tue, Feb 6, 2024 at 9:22 PM Larry Garfield > wrote: > > > > 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 func
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
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] Feature request: https://github.com/php/php-src/issues/13301
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] Feature request: https://github.com/php/php-src/issues/13301
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 co
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
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
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
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 > > &
Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
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 >
[PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
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
