[PHP-DEV] Re: [Discussion] FFI in PHP

that takes two numbers in and gives you the sum of them. ```rust #[no_mangle] pub extern fn add(a: i32, b: i32) -> i32 { a + b } ``` with the Cargo.toml file containing: ``` [package] name = "math" version = "0.1.0" authors = ["Alex Bowers <bowersb...@gmail.com

[PHP-DEV] [Discussion] FFI in PHP

in and gives you the sum of them. ```rust #[no_mangle] pub extern fn add(a: i32, b: i32) -> i32 { a + b } ``` with the Cargo.toml file containing: ``` [package] name = "math" version = "0.1.0" authors = ["Alex Bowers <bowersb...@gmail.com>"] [dependencies] [

Re: [PHP-DEV] [RFC] [VOTE] Libsodium as a core extension in PHP 7.2

On 4 February 2017 at 00:04, Nikita Popov wrote: > On Sat, Feb 4, 2017 at 12:54 AM, Scott Arciszewski > wrote: > > > On Fri, Feb 3, 2017 at 6:19 PM, Yasuo Ohgaki wrote: > > > > > Hi Scott and all, > > > > > > On Sat, Feb 4, 2017 at

Re: [PHP-DEV] Re: [Concept] Magic Casting

So I guess the new logic is, that the class being casted to, MUST have zero or one required parameter. It must not cast if already the same type. It must not cast to its own type (infinite loop)

Re: [PHP-DEV] Re: [Concept] Magic Casting

On 2 December 2016 at 15:17, Andrey Andreev wrote: > Honestly, I don't see how a new method is in any way beneficial. I see your point now, and actually agree. An interface would be suitable and probably a better way to implement it.

Re: [PHP-DEV] Re: [Concept] Magic Casting

Sorry for dupe, hit reply not reply-all. I don't see how the interface is equivalent. The benefit of this, is that you can convert types passed into a method to the type you expect automagically, Castable wouldn't allow that, only a new magic method (or reflection and user land code possibly?)

Fwd: [PHP-DEV] Re: [Concept] Magic Casting

Sorry for forward, hit reply not reply all. -- Forwarded message -- From: Alex Bowers <bowersb...@gmail.com> Date: 2 December 2016 at 14:16 Subject: Re: [PHP-DEV] Re: [Concept] Magic Casting To: David Rodrigues <david.pro...@gmail.com> var_dump was just an example t

Fwd: [PHP-DEV] Re: [Concept] Magic Casting

Sorry for forward. Hit reply, not reply-all. -- Forwarded message -- From: Alex Bowers <bowersb...@gmail.com> Date: 2 December 2016 at 14:31 Subject: Re: [PHP-DEV] Re: [Concept] Magic Casting To: David Rodrigues <david.pro...@gmail.com> Another benefit this would giv

Re: [PHP-DEV] Re: [Concept] Magic Casting

On 2 December 2016 at 14:46, Andrey Andreev wrote: > It enables magic behavior, that's the opposite of enforcement ... If you > want to enFORCE something, you force the developer to do something, you > don't auto-magically do the thing for them. This magic behaviour would be

Re: [PHP-DEV] Re: [Concept] Magic Casting

On 2 December 2016 at 14:46, Andrey Andreev wrote: > What I meant is - you cannot cast to a class that requires more than one > dependency to be instantiated - that's the obvious limitation. Ah yes, that is certainly true, unless the other parameters can be determined /

Re: [PHP-DEV] Re: [Concept] Magic Casting

On 2 December 2016 at 14:46, Andrey Andreev wrote: > A magic method is essentially an implicit interface ... > The interface itself does nothing. But when it is implemented, the engine > will know that the class constructor is public and accepts a single > parameter - thus,

Re: [PHP-DEV] Re: [Concept] Magic Casting

Damn. I must have done that to a lot of emails. Gonna have to resend them all when I get home. Sorry folks for dupes. On 2 December 2016 at 14:46, Andrey Andreev <n...@devilix.net> wrote: > Hi again, > > On Fri, Dec 2, 2016 at 4:19 PM, Alex Bowers <bowersb...@gmail.com> wr

[PHP-DEV] Re: [Concept] Magic Casting

And because the email formatting appears bad (at least in externals.io) Here it is in a gist: https://gist.github.com/alexbowers/9520c8df746249ecae2d9c7aad2e54ae

[PHP-DEV] Re: [Concept] Magic Casting

Sorry, forgot a little bit of information. If the type passed is already satisfactory (an instance), then __cast is NOT called.

[PHP-DEV] [Concept] Magic Casting

Hello All, In PHP we currently have the ability to type hint classes in method signatures, however, sometimes it would be useful to convert the items to a different instance / type. An example is collections and arrays. If implemented properly, an array and a collection could be used

Re: [PHP-DEV] number_format() = "-0.00"

Php doesn't have a concept of negative zero except in a string instance. And the main use case for this is displaying the number as a string which has very few real world use cases as being a negative zero. On 25 Nov 2016 9:05 am, "Craig Duncan" wrote: > On 25 November 2016

Re: [PHP-DEV] Re: [RFC] Traits with interfaces

Would a fair solution to this be having the using class define whether to inherit the implementations? Perhaps a new keyword akin to 'propagated', so the code will read Class Foo { Use propagated TraitName; } Only then will the implementations from that trait bubble through. If it isn't

Re: [PHP-DEV] Re: [VOTE] Reclassify E_STRICT notices

Is the last one really a strict? Sounds like it should be a warning to me. Similar to when you for each over something not an array On 1 Apr 2015 15:58, Nikita Popov nikita@gmail.com wrote: On Wed, Mar 25, 2015 at 5:14 PM, Nikita Popov nikita@gmail.com wrote: On Sun, Mar 15, 2015 at

Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?

I think deprecating it is a good idea, and looking at the documentation it does mention that not providing it is the intended option; so it isn't a complete surprise for it to become deprecated. On 31 March 2015 at 19:49, Anthony Ferrara ircmax...@gmail.com wrote: All, Ever since we

Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

The deadline for PHP 7 features has passed On 26 March 2015 at 20:54, Michael Morris tendo...@gmail.com wrote: Per PHPsadness... http://phpsadness.com/sad/30 Since 7 is allowed to have BC breaks this would be the time to fix this. I'll let someone with more seniority actually write this

Re: [PHP-DEV] RFC - Array slice syntactic sugar

Would it make more sense then to have a RFC for array by positional index. No range or anything initially (that will be a separate RFC), but simply to get the value of an array by positional index? $array[*4] to get the item in position 4.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

I've tried implementing python style slice on both strings and arrays in the past (I don't seem to have an existing branch with it in any more though it seems). The biggest problems I hit were regarding the syntax, the functionality itself worked. If you've got a link to your messaging

Re: [PHP-DEV] RFC - Array slice syntactic sugar

That said, I'm a little older and wiser than I was then, I'd still be interested in looking at this. I'll try and come up with _something_ that works over the weekend. I started on the code last night, but didn't get very far. I got it to match the T_COLON, but no logic or parsing has been

Re: [PHP-DEV] RFC - Array slice syntactic sugar

The @ symbol in my examples is not a special marker that is meaningful on its own; the parser wouldn't even see it as a separate token. The syntax for key access is $array[$key], the syntax for positional access would be $array[@$position]; chosen to look similar, but one is not a special

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 23:03, Stanislav Malyshev smalys...@gmail.com wrote: $array[*1:4] by reference - what is actually passed? Implementation is not something I have looked into for this yet, so I am unsure how this would be possible; but by passing $array[*1:4], you'd be passing an extracted

Re: [PHP-DEV] RFC - Array slice syntactic sugar

It's an alternative syntax Learn something new every day. I guess this RFC will need to support both then for consistency reasons; so it will be down to the end user to determine how they want to separate them if they choose to. But I don't think we should only match {} for strings and [] for

Re: [PHP-DEV] RFC - Array slice syntactic sugar

We also need to consider then the possibility of setting data by position. What should $array[@1:3] = [1,2,3] do? Should it overwrite the values there, and append any that don't exist, or should it be a parse error?

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 13:04, Rowan Collins rowan.coll...@gmail.com wrote: $version{4:} = '7!'; I'm sure this is a slight oversight on your end, but just to check. The change of using {} instead of [] is not because its a string, and is just a typo / example correct?

[PHP-DEV] RFC Karma

Good day, My Wiki username is: alexbowers I have an RFC currently under gauge within the thread (link: https://marc.info/?l=php-internalsm=142679821024794w=2 ) Which seems to be getting some positive reviews, and so I would like to write an official RFC to be placed into discussion. Thanks,

Re: [PHP-DEV] RFC - Array slice syntactic sugar

, assuming this one gets accepted to be expanded upon. On 20 March 2015 at 13:04, Rowan Collins rowan.coll...@gmail.com wrote: Alex Bowers wrote on 20/03/2015 12:32: We also need to consider then the possibility of setting data by position. What should $array[@1:3] = [1,2,3] do? Should

Re: [PHP-DEV] RFC - Array slice syntactic sugar

provided and clear naming for the differences between them. On 20 March 2015 at 13:21, Rowan Collins rowan.coll...@gmail.com wrote: Alex Bowers wrote on 20/03/2015 13:10: $array['x':'z'] = []; // Remove all elements with keys between 'x' and 'z', inclusive I believe i mentioned

Re: [PHP-DEV] RFC - Array slice syntactic sugar

at 14:41, Rowan Collins rowan.coll...@gmail.com wrote: Alex Bowers wrote on 20/03/2015 13:40: Still not sure how we can implement a range of strings. But since thats for a different feature, I'll leave that issue for now. I can't resist a quick answer: if you can define a key-based slice

Re: [PHP-DEV] RFC - Array slice syntactic sugar

If your branch is available on github let me know, more than happy work on it with you. I'll publish it tonight (GMT), I'm at work at the moment. Thanks!

Re: [PHP-DEV] RFC - Array slice syntactic sugar

The latest comments in this thread are talking about having a symbol before the range to show that it is by positional index. Current propositions for this are ^ and *. I'm not sure how such operation would be useful Anywhere on the front-end where a foreach() is used, and expects at most say,

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 20:52, Stanislav Malyshev smalys...@gmail.com wrote: I'm not sure how such operation would be useful, and it definitely would not be intuitive, as $array[0] and $array[0:1] (assuming non-inclusive semantic, or [0:0] with inclusive semantics) would return completely

Re: [PHP-DEV] RFC - Array slice syntactic sugar

Certainly it breaks BC (and would presumably have to wait until PHP 8), but if we were starting from scratch today, why would it make sense to have two syntaxes that do exactly the same thing? Maybe you misunderstand me, I am against using two syntaxes for different things.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

That's why I propose a new syntax such as $thing[@0], $thing[@-1] I have to agree that a new syntax will be required by this. On 20 March 2015 at 18:17, Rowan Collins rowan.coll...@gmail.com wrote: Leigh wrote on 20/03/2015 16:17: For $thing[-1] I think this only works for strings (and I

Re: [PHP-DEV] RFC - Array slice syntactic sugar

Is everybody happy with the RFC being called 'Slice Operator', or is there a better name for it? On 20 March 2015 at 18:17, Rowan Collins rowan.coll...@gmail.com wrote: Leigh wrote on 20/03/2015 16:17: For $thing[-1] I think this only works for strings (and I have this implemented, should

Re: [PHP-DEV] RFC Karma

Grand. Thank you. On 20 March 2015 at 19:00, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Mar 20, 2015 at 2:56 PM, Alex Bowers bowersb...@gmail.com wrote: Good day, My Wiki username is: alexbowers I have an RFC currently under gauge within the thread (link: https://marc.info/?l=php

Re: [PHP-DEV] RFC - Array slice syntactic sugar

Yes, I'm very conscious of the substantial BC break, which is why I would target PHP 8 (or even 9, following a deprecation cycle). I would guess PHP 8, since you can deprecate things at 7.x Either way, if you make this a separate thread so we don't get off topic, and i'm sure you'll get many

Re: [PHP-DEV] RFC - Array slice syntactic sugar

reading. But variable names and so on should be used to help distinguish from array or strings anyway. On 20 Mar 2015 17:02, Vik Hudec vikhu...@yahoo.com wrote: Hi Alex, On Fri, 2015-03-20, at 14:52, Alex Bowers wrote: But I don't think we should only match {} for strings and [] for arrays

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 16:17, Leigh lei...@gmail.com wrote: $thing[-1:] is in scope for arrays though How would this work for slicing? Since doing [@-1:] would mean get the last element to the end. And doing [@1:-1] is the exact same as doing [@1:] since -1 and blank both mean the end.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

I'd be tempted to introduce the ability to get a single element by position as well Absolutely agree. Can we agree on a symbol do you think, or should the RFC continue for the symbol discussion?

Re: [PHP-DEV] RFC - Array slice syntactic sugar

IMHO, stick to offsets in the first instance, this is a slice notation, first order of business is to make it behave like array_slice (+on strings). Assoc key based slicing feels pretty wrong to me at this point. I have to agree, we are getting ahead of ourselves. A quick summary of what

Re: [PHP-DEV] RFC - Array slice syntactic sugar

of this RFC. On 20 March 2015 at 16:17, Leigh lei...@gmail.com wrote: On Mar 20, 2015 4:00 PM, Alex Bowers bowersb...@gmail.com wrote: IMHO, stick to offsets in the first instance, this is a slice notation, first order of business is to make it behave like array_slice (+on strings). Assoc key based

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 20:10, Sean Coates s...@seancoates.com wrote: That’s no different than `@` being invalid because it’s already in use. The syntax would be [*from:to], which would currently throw a parse error (since asterisk is required to be placed between two numbers), so this would be

Re: [PHP-DEV] RFC - Array slice syntactic sugar

There’s no existing unary form of * and ^, though, so I think they’d both be available in this context (^ is my preference). I think that is also my preference too. On 20 March 2015 at 20:17, John Bafford jbaff...@zort.net wrote: On Mar 20, 2015, at 16:10, Sean Coates s...@seancoates.com

Re: [PHP-DEV] RFC - Array slice syntactic sugar

The concept itself can still work, but it’d need a token other than @. This is the symbol currently being used for examples, but thats all it is currently. Nothing is set in stone (and most likely will change), not just for this reason but for the reason that I mentioned earlier in the thread

Re: [PHP-DEV] RFC - Array slice syntactic sugar

// alternative old foreach(array_slice($results, 0, 9) as $result) { echo $result . \n; // 1 2 3 4 5 6 7 8 9 } Not so bad, in my opinion. To be the same, your example would have to be: // alternative old foreach(array_slice($results, 0, 9, true) as $result) { echo

Re: [PHP-DEV] RFC - Array slice syntactic sugar

Why not use array_slice for it? There certainly are ways to do most of what this RFC covers, however most of them don't lend themselves well to clean code in my opinion. Thats why this RFC is listed as being syntactic sugar. On 20 March 2015 at 21:30, Stanislav Malyshev smalys...@gmail.com

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 22:12, Stanislav Malyshev smalys...@gmail.com wrote: You're not using the keys in foreach, so why you need to preserve them? This was merely an example of the features equal part in current code, not a real life use case. Using the new syntax will keep the keys preserved,

Re: [PHP-DEV] RFC - Array slice syntactic sugar

I'm not sure why it would duplicate the item like that. My interpretation of $array[$start:$end] would be an array containing all those elements of $array with a position more than or equal to $start, but less than or equal to $end ($position = $start $position = $end). I agree with this

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 19 March 2015 at 21:11, Larry Garfield la...@garfieldtech.com wrote: On 3/19/15 4:06 PM, Alex Bowers wrote: I've had a quick scan of the list at https://wiki.php.net/rfc but cannot seem to find anything. I'll read more carefully through, or is there a different list elsewhere which I

[PHP-DEV] RFC - Array slice syntactic sugar

This email is just to gauge the response for some syntactic sugar to be added to PHP in regard to slicing an array. My proposal is something similar to Pythons slice, in PHP this would look like: $slided = $array[1:4] This will get the elements in positions 1,2,3,4. (1 through 4 inclusive),

Re: [PHP-DEV] RFC - Array slice syntactic sugar

I've had a quick scan of the list at https://wiki.php.net/rfc but cannot seem to find anything. I'll read more carefully through, or is there a different list elsewhere which I should look at? On 19 March 2015 at 21:03, Larry Garfield la...@garfieldtech.com wrote: On 3/19/15 3:49 PM, Alex