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

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

On Thu, Feb 8, 2024 at 8:57 PM Григорий Senior PHP / Разработчик Web <6562...@gmail.com> wrote: > > 1. Do some benchmark with > > ``` > > function a($a, $b) > { > return $a + $b; > } > > function aa($a, $b) > { > throw new \Exception(); > > return $a + $b; > } > > $bag = []; > >

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

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

On Thu, Feb 8, 2024, at 11:15 AM, Григорий Senior PHP / Разработчик Web wrote: > 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

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

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

On Thu, Feb 8, 2024, 12:12 Alexander Pravdin wrote: > On Thu, Feb 8, 2024 at 6:25 PM Григорий Senior PHP / Разработчик Web > <6562...@gmail.com> wrote: > > > > PHPStan is out the case. > > > > May I know why is it out? > > I'm actively using it in my projects and it helps me a lot to not > relax

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

On Thu, Feb 8, 2024 at 6:25 PM Григорий Senior PHP / Разработчик Web <6562...@gmail.com> wrote: > > PHPStan is out the case. > May I know why is it out? I'm actively using it in my projects and it helps me a lot to not relax and write safe code. It also helps a lot in cleaning up legacy code.

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

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

On Thu, Feb 8, 2024 at 4:02 PM Григорий Senior PHP / Разработчик Web <6562...@gmail.com> wrote: > > 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

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

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

On Thu, Feb 8, 2024 at 2:29 AM Григорий Senior PHP / Разработчик Web <6562...@gmail.com> wrote: > 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. Sorry for answering not directly to

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

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

On Wed, Feb 7, 2024, at 12:55 AM, Alex Wells wrote: > 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

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.

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

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

On Wed, Feb 7, 2024, at 10:21 AM, Robert Landers wrote: >> 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

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

On Wed, Feb 7, 2024 at 11:27 AM Григорий Senior PHP / Разработчик Web <6562...@gmail.com> wrote: > > 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.

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

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

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: > > -

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

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

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

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

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

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

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

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

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

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

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

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

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

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"

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

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

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

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

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)

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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)

Re: [PHP-DEV] Feature Request: dependencies container

Re-writing with the internals ML in CC On Mon, Aug 3, 2020, 06:16 3u93n3 wrote: > > 2. Setter injection (as well as property injection, and also the > proposed `__inject`) leads to temporal coupling smells. Explained > otherwise, your object instances are not "functioning" right after >

Re: [PHP-DEV] Feature Request: dependencies container

Heya, On Mon, Aug 3, 2020, 05:32 3u93n3 wrote: > The main idea is to take control over objects creation and injecting > dependencies. > > 1. Some of them are provided through constructor (those, which could only > be retrieved right before instantiating our object). > 2. Others are provided

Re: [PHP-DEV] Feature request - allow to append multiple elements to an array

On Sun, Mar 29, 2020 at 12:07 AM Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote: > Hi all PHP gurus! > > This is a feature request / RFC for the following use-case: > > $res = []; > foreach ($arr as $i) { > foreach (make_res($i) as $v) { > $res[] = $v; > } > } > > Array_merge in loop is

RE: [PHP-DEV] Feature request - allow to append multiple elements to an array

>> $arr[] = 1, 2, 3; // push these 3 values >> $arr[] = 1, 2, ... [3, 4, 5], 6; // push these 6 values > >Just to play with this... - normally an assignment evaluates to the >value being assigned: > >var_dump($arr[] = 1); // int(1) > >What would this produce? > >var_dump($arr[] = 1, 2, 3); > >The

Re: [PHP-DEV] Feature request - allow to append multiple elements to an array

On Sun, Mar 29, 2020 at 4:08 AM Iván Arias wrote: > > $arr[] = 1, 2, 3; // push these 3 values > $arr[] = 1, 2, ... [3, 4, 5], 6; // push these 6 values Just to play with this... - normally an assignment evaluates to the value being assigned: var_dump($arr[] = 1); // int(1) What would this

Re: [PHP-DEV] Feature request - allow to append multiple elementsto an array

On 29.03.2020 at 21:05, Manuel Canga wrote: > Maybe, PHP needs array_flatten like Ruby: > https://apidock.com/ruby/Array/flatten > > In this way, above code would be equal to: > > $res = array_flatten( array_map('make_res', $arr) ); You can already do $res =

Re: [PHP-DEV] Feature request - allow to append multiple elements to an array

Hi, Internals > > Em sáb., 28 de mar. de 2020 às 20:07, Michael Voříšek - ČVUT FEL < > voris...@fel.cvut.cz> escreveu: > > > Hi all PHP gurus! > > > > This is a feature request / RFC for the following use-case: > > > > $res = []; > > foreach ($arr as $i) { > > foreach (make_res($i)

Re: [PHP-DEV] Feature request - allow to append multiple elements to an array

tps://aka.ms/ghei36> From: David Rodrigues Sent: Sunday, March 29, 2020 5:32:32 AM To: Michael Voříšek - ČVUT FEL Cc: PHP Internals Subject: Re: [PHP-DEV] Feature request - allow to append multiple elements to an array I think it useful, despite that it could b

Re: [PHP-DEV] Feature request - allow to append multiple elements to an array

I think it useful, despite that it could be done by using array_push() as Woortmann said. Anyway, I think valid a new proposal for thinks like that. But I will suggests this: $arr[] = ... $items; Atenciosamente, David Rodrigues Em sáb., 28 de mar. de 2020 às 20:07, Michael Voříšek - ČVUT FEL

Re: [PHP-DEV] Feature request - allow to append multiple elements to an array

Hi Michael, why not simply use array_push with multiple arguments? Something like: $a = []; array_push($a, ...array_fill(0, 10, 'x')); echo print_r($a, true); Cheers, Enno Am 29.03.2020 um 00:07 schrieb Michael Voříšek - ČVUT FEL: Hi all PHP gurus! This is a feature request / RFC for the

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

>> >Envoyé : mardi 4 octobre 2016 16:21 >> >À : Pascal KISSIAN <php-mailing-l...@lool.fr> >> >Cc : internals@lists.php.net >> >Objet : Re: [PHP-DEV] Feature Request: inline pseudo-instruction >> > >> >On 2016-10-04 14:33,

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

>Cc : internals@lists.php.net > >Objet : Re: [PHP-DEV] Feature Request: inline pseudo-instruction > > > >On 2016-10-04 14:33, Pascal KISSIAN wrote: > >> I have an application where a small file is included at multiple > >> places. > >> > >> Th

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

Hi, On 10/04/2016 01:33 PM, Pascal KISSIAN wrote: Hi everybody, I have an application where a small file is included at multiple places. So far so good. The problem is that this include consists in a small piece of code which is inside a multi-level loop. The include is done about an

RE: [PHP-DEV] Feature Request: inline pseudo-instruction

] Envoyé : mardi 4 octobre 2016 17:52 À : Bob Weinand Cc : Pascal KISSIAN; PHP internals list Objet : Re: [PHP-DEV] Feature Request: inline pseudo-instruction 2016-10-04 17:39 GMT+02:00 Bob Weinand <bobw...@hotmail.com>: > Am 4.10.2016 um 16:33 schrieb Pascal KISSIAN <php-mailing-

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

é : mardi 4 octobre 2016 16:21 > >> À : Pascal KISSIAN <php-mailing-l...@lool.fr> > >> Cc : internals@lists.php.net > >> Objet : Re: [PHP-DEV] Feature Request: inline pseudo-instruction > >> > >> On 2016-10-04 14:33, Pascal KISSIAN wrote: >

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

;> Cc : internals@lists.php.net >> Objet : Re: [PHP-DEV] Feature Request: inline pseudo-instruction >> >> On 2016-10-04 14:33, Pascal KISSIAN wrote: >>> I have an application where a small file is included at multiple >>> places. >>> >>> Th

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

On 10/4/2016 7:33 AM, Pascal KISSIAN wrote: -Message d'origine- De : Lauri Kenttä [mailto:lauri.ken...@gmail.com] Envoyé : mardi 4 octobre 2016 16:21 À : Pascal KISSIAN <php-mailing-l...@lool.fr> Cc : internals@lists.php.net Objet : Re: [PHP-DEV] Feature Request: inline

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

On 10/4/2016 4:33 AM, Pascal KISSIAN wrote: Hi everybody, I have an application where a small file is included at multiple places. So far so good. The problem is that this include consists in a small piece of code which is inside a multi-level loop. The include is done about an average of

RE: [PHP-DEV] Feature Request: inline pseudo-instruction

>-Message d'origine- >De : Lauri Kenttä [mailto:lauri.ken...@gmail.com] >Envoyé : mardi 4 octobre 2016 16:21 >À : Pascal KISSIAN <php-mailing-l...@lool.fr> >Cc : internals@lists.php.net >Objet : Re: [PHP-DEV] Feature Request: inline pseudo-instruction > &

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

On 2016-10-04 14:33, Pascal KISSIAN wrote: I have an application where a small file is included at multiple places. The include is done about an average of 100.000 times . I'm just wondering if you have ever heard of functions? You really should write a function, include it only once, and

Re: [PHP-DEV] feature-request : html + css logging in apache logs (example for the rest of the unix community too)

Thank you. I'm not insisting it become the default, just thought it'd be handy.. As for the RFC, i'll do it after a nice long nap OK :) I dont know anything about the internals of PHP, i'm a PHP + HTML developer exclusively, but i'll try to give you some implementation suggestions in what i can

Re: [PHP-DEV] feature-request : html + css logging in apache logs (example for the rest of the unix community too)

Hi 2016-08-28 5:07 GMT+02:00 Rene Veerman : > > it would really cut my development time in more than half if you could add > "all of this" (it's deadsimple and a few hours work imo) to the next > versions of PHP (and please make it the default, you can

Re: [PHP-DEV] feature request : gzip caching

i'm working on comprehensive caching (and true obfuscation) with PHP for HTML, CSS, JS and JSON.. it's nearly done, and i've always served my javascript as a concatenated file.. i have well over 20 different sourcefiles you know.. takes too long with the http overhead for them to be in seperate

Re: [PHP-DEV] Feature request and RFC

On 08/03/2015 15:45, Grégory Planchat wrote: class BarSortable implements Sorter { public function sort(Sortable $collection) { $previousKey = null; $previousElement = null; foreach ($collection as $key = $element) { if ($previousKey === null) {

Re: [PHP-DEV] Feature request and RFC

Le 08/03/2015 19:05, Rowan Collins a écrit : On 08/03/2015 15:45, Grégory Planchat wrote: class BarSortable implements Sorter { public function sort(Sortable $collection) { $previousKey = null; $previousElement = null; foreach ($collection as $key = $element) {

Re: [PHP-DEV] Feature request and RFC

Le 24/02/2015 20:20, Thomas Gielfeldt a écrit : 2015-02-24 17:36 GMT+01:00 Benjamin Eberlei kont...@beberlei.de: Hi, On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt tho...@gielfeldt.dk wrote: Hi internals. I've made PR proposing a feature request: A new interface Sortable.

Re: [PHP-DEV] Feature request and RFC

Le 08/03/2015 15:19, Rowan Collins a écrit : On 08/03/2015 10:51, Grégory Planchat wrote: Le 24/02/2015 20:20, Thomas Gielfeldt a écrit : 2015-02-24 17:36 GMT+01:00 Benjamin Eberlei kont...@beberlei.de: Hi, On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt tho...@gielfeldt.dk wrote: Hi

Re: [PHP-DEV] Feature request and RFC

On 08/03/2015 10:51, Grégory Planchat wrote: Le 24/02/2015 20:20, Thomas Gielfeldt a écrit : 2015-02-24 17:36 GMT+01:00 Benjamin Eberlei kont...@beberlei.de: Hi, On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt tho...@gielfeldt.dk wrote: Hi internals. I've made PR proposing a feature

Re: [PHP-DEV] Feature request and RFC

Thomas Gielfeldt wrote on 24/02/2015 16:17: Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I would like to create and RFC describing this in more detail, and perhaps get a voting on. I think the reason

Re: [PHP-DEV] Feature request and RFC

2015-02-24 17:36 GMT+01:00 Benjamin Eberlei kont...@beberlei.de: Hi, On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt tho...@gielfeldt.dk wrote: Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I

Re: [PHP-DEV] Feature request and RFC

2015-02-24 17:36 GMT+01:00 Benjamin Eberlei kont...@beberlei.de: Hi, On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt tho...@gielfeldt.dk wrote: Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I

Re: [PHP-DEV] Feature request and RFC

2015-02-24 17:36 GMT+01:00 Benjamin Eberlei kont...@beberlei.de: Hi, On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt tho...@gielfeldt.dk wrote: Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I

Re: [PHP-DEV] Feature request and RFC

2015-02-25 13:21 GMT+03:00 Thomas Gielfeldt tho...@gielfeldt.dk: I have some more proposals for how to implement this interface. Should we create an RFC for purposes of discussion, or do you usually do this in the mailing lists? Best interface is described by the one single method: sort()

Re: [PHP-DEV] Feature request and RFC

2015-02-25 11:31 GMT+01:00 Alexander Lisachenko lisachenko...@gmail.com: 2015-02-25 13:21 GMT+03:00 Thomas Gielfeldt tho...@gielfeldt.dk: I have some more proposals for how to implement this interface. Should we create an RFC for purposes of discussion, or do you usually do this in the

Re: [PHP-DEV] Feature request and RFC

2015-02-25 13:37 GMT+03:00 Thomas Gielfeldt tho...@gielfeldt.dk: Yeah, but the problem with this, is that your class' sort method, you have to implement all the possible permutations the flags can produce. This basically just squeezes the 11 functions into 1. The 1 interface with sort() and

Re: [PHP-DEV] Feature request and RFC

2015-02-25 12:15 GMT+01:00 Alexander Lisachenko lisachenko...@gmail.com: 2015-02-25 13:37 GMT+03:00 Thomas Gielfeldt tho...@gielfeldt.dk: Yeah, but the problem with this, is that your class' sort method, you have to implement all the possible permutations the flags can produce. This

Re: [PHP-DEV] Feature request and RFC

Hi! I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I would like to create and RFC describing this in more detail, and perhaps get a voting on. Can't you sort any class that provides ordered list of elements and

Re: [PHP-DEV] Feature request and RFC

2015-02-24 20:49 GMT+01:00 Stanislav Malyshev smalys...@gmail.com: Hi! I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I would like to create and RFC describing this in more detail, and perhaps get a voting

Re: [PHP-DEV] Feature request and RFC

Hi, On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt tho...@gielfeldt.dk wrote: Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I would like to create and RFC describing this in more detail, and

Re: [PHP-DEV] Feature request and RFC

2015-02-24 17:36 GMT+01:00 Benjamin Eberlei kont...@beberlei.de: Hi, On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt tho...@gielfeldt.dk wrote: Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I

Re: [PHP-DEV] feature request : easy shared memory

On Thu, 14 Mar 2013 07:05:03 -, rene7705 rene7...@gmail.com wrote: Hi. I'd like to build a replacement for SQL (yes, talk about an ambitious project! ;), because the constant transferal of data in and out of SQL from Javascript (where everything might as well be object-oriented and

Re: [PHP-DEV] feature request : easy shared memory

great! :) this will do nicely. is there much overhead for storing and fetching these variables? (ideally I would like to get a pointer) On Thu, Mar 14, 2013 at 12:45 PM, Nikita Nefedov inefe...@gmail.com wrote: On Thu, 14 Mar 2013 07:05:03 -, rene7705 rene7...@gmail.com wrote: Hi.

Re: [PHP-DEV] feature request : easy shared memory

Hello, 2013/3/14 rene7705 rene7...@gmail.com great! :) this will do nicely. is there much overhead for storing and fetching these variables? (ideally I would like to get a pointer) Unfortunately there is. Every object stored in APC has to be serialised first and then unserialised on

Re: [PHP-DEV] feature request : easy shared memory

On 3/14/13 10:31 AM, rene7705 wrote: (ideally I would like to get a pointer) PHP's environment is torn down after every request, so no matter what the mechanism you generally can't store anything that can't be serialized. See also https://www.google.com/search?q=php+shared+memory Steve

Re: [PHP-DEV] feature request : easy shared memory

Am 14.3.2013 um 16:46 schrieb Lazare Inepologlou linep...@gmail.com: Hello, 2013/3/14 rene7705 rene7...@gmail.com great! :) this will do nicely. is there much overhead for storing and fetching these variables? (ideally I would like to get a pointer) Unfortunately there is. Every

Re: [PHP-DEV] feature request : easy shared memory

Am 14.3.2013 um 18:14 schrieb Rasmus Lerdorf ras...@lerdorf.com: On 03/14/2013 09:13 AM, Bob Weinand wrote: And there is no possibility to store the zval as raw binary data like in memory (deep copy?) So that you only have to copy from ram? And replace the pointers to the place in the

Re: [PHP-DEV] feature request : easy shared memory

On 3/14/13 12:28 PM, Bob Weinand wrote: Am 14.3.2013 um 18:14 schrieb Rasmus Lerdorf ras...@lerdorf.com: On 03/14/2013 09:13 AM, Bob Weinand wrote: And there is no possibility to store the zval as raw binary data like in memory (deep copy?) So that you only have to copy from ram? And replace

Re: [PHP-DEV] feature request : easy shared memory

On 03/14/2013 09:13 AM, Bob Weinand wrote: And there is no possibility to store the zval as raw binary data like in memory (deep copy?) So that you only have to copy from ram? And replace the pointers to the place in the string? This must be possible I think. And should be faster. shmop

Re: [PHP-DEV] Feature Request

realpath function do this for you. It returns the absolute path, if file exists. Otherwise, returns null. On Wed, Jan 4, 2012 at 2:18 PM, Keloran ava...@gmail.com wrote: I dont seem to have the karma for doing this in RFC so ill propose it here, and once karma make an RFC Is it possible to

Re: [PHP-DEV] Feature Request

On Wed, Jan 4, 2012 at 5:18 PM, Keloran ava...@gmail.com wrote: I dont seem to have the karma for doing this in RFC so ill propose it here, and once karma make an RFC Is it possible to have a 2nd option on file_exists so that it returns the path you specified --Example $cFile =

RE: [PHP-DEV] Feature Request

pretty sure it's a bad idea because this function expected to return true/false Not to mention it is completely unnecessary since you can assign path to a var $file = '/path/file.txt'; if(!file_exists($file)){ // you already have access to $file } Dmitri Snytkine Web Developer Ultra Logistics,

Re: [PHP-DEV] Feature Request

I agree with Dmitri and Ferenc. -1 on this idea, it's unnecessary. the reason for this is simple actually at the moment if you want to include a file for usage but want to check it exists you have todo the following if (file_exists(/file/located/here.php)) {  $cFile = /file/located/here.php;

Re: [PHP-DEV] Feature Request

On 04/01/12 17:18, Keloran wrote: which can if your doing lots of checking alot of extra code for no reason, or if you want to use variables, lots of louse variables just for something that could be pulled from the request I don't think it would mean 'a lot of code', but if it bothers you in

Re: [PHP-DEV] Feature request : Self caching of .php files for wide multi backend setups.

Constantin B wrote: Hello, i'm not sure its the right place to post this message, so redirect me if i'm wrong. Here the problematic : We are alot running php across multiple backend servers and we all know that we need to syncronise the php sources usualy we do that with rsync , some

Re: [PHP-DEV] Feature request : Self caching of .php files for wide multi backend setups.

There is nothing simple about it when it comes to a portable implementation across all platforms which is what it would have to be if it was in PHP. In your case, you don't need it to be portable, you just need it to work on your configuration, and there are all sorts of ways you can solve it

Re: [PHP-DEV] Feature request : Self caching of .php files for wide multi backend setups.

I was thinking that portable and very simple implementation in php would be much more used in real world than these experimental too abstract implementations. but i guess i'm wrong. 2007/8/3, Rasmus Lerdorf [EMAIL PROTECTED]: Constantin B wrote: Hello, i'm not sure its the right place

Re: [PHP-DEV] Feature request : Self caching of .php files for wide multi backend setups.

Hi Constantin, That is quite a difficult setup you have there. You should have a look if there is not a simpler way to accomplish whatever this setup is for. That said, you should have a look at DRBD (http://www.drbd.org), which should be able to solve your problems. It detects file changes

Re: [PHP-DEV] Feature request

Richard Lynch schrieb: On Thu, November 9, 2006 9:13 pm, Andi Gutmans wrote: ?php function foo() { return array(1,2,3,4,5,6); } echo foo()[4]; // it that It looks a bit perl-ish indeed but I don't see much trouble in having that it people really need it... -0.3 :-) The thing is,

  1   2   >