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 "]
[dependencies
n 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 "] [dependencies]
[lib] name = "math" c
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 5:44 AM, Scott Arciszewski >
> > > wrote:
> > >
> > >> I've op
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)
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.
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?) wo
Sorry for forward, hit reply not reply all.
-- Forwarded message --
From: Alex Bowers
Date: 2 December 2016 at 14:16
Subject: Re: [PHP-DEV] Re: [Concept] Magic Casting
To: David Rodrigues
var_dump was just an example to "show what type the variable is", and
completel
Sorry for forward. Hit reply, not reply-all.
-- Forwarded message --
From: Alex Bowers
Date: 2 December 2016 at 14:31
Subject: Re: [PHP-DEV] Re: [Concept] Magic Casting
To: David Rodrigues
Another benefit this would give frameworks / user land code is the ability
to mock
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 for enforcement, be
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 / derived (e.g., injection
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, also knowing that it c
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 wrote:
> Hi again,
>
> On Fri, Dec 2, 2016 at 4:19 PM, Alex Bowers wrote:
>
>> I don't see how the
And because the email formatting appears bad (at least in externals.io)
Here it is in a gist:
https://gist.github.com/alexbowers/9520c8df746249ecae2d9c7aad2e54ae
Sorry, forgot a little bit of information.
If the type passed is already satisfactory (an instance), then __cast is
NOT called.
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 interchangea
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 at 08:58, Sherif Rama
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 declar
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" wrote:
> On Wed, Mar 25, 2015 at 5:14 PM, Nikita Popov
> wrote:
>
> > On Sun, Mar 15, 2015 at 4:46 PM, Nikita Popov
> > wrote:
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 wrote:
> All,
>
> Ever since we introduced password_hash()
The deadline for PHP 7 features has passed
On 26 March 2015 at 20:54, Michael Morris 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 up - but plea
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.
On 20 March 2015 at 23:03, Stanislav Malyshev 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 array which is a
On 20 March 2015 at 22:12, Stanislav Malyshev 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, therefore any examp
>
> 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 wrote:
> Hi!
>
> >
>
> // 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
On 20 March 2015 at 20:52, Stanislav Malyshev 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
> different things. That
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, 1
>
> 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 wrote:
>
> On Mar 20, 2015, at 16:10, Sean Coates wrote:
>
> >> I posted four sug
On 20 March 2015 at 20:10, Sean Coates 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 different.
Alternati
>
> 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
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 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 probably RFC it)
Grand.
Thank you.
On 20 March 2015 at 19:00, Ferenc Kovacs wrote:
>
> On Fri, Mar 20, 2015 at 2:56 PM, Alex Bowers wrote:
>
>> Good day,
>>
>> My Wiki username is: alexbowers
>>
>> I have an RFC currently under gauge within the thread (link:
>
> 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 wrote:
> Leigh wrote on 20/03/2015 16:17:
>
>>
>> For $thing[-1] I think this only works for strings (and I have this
>> im
>
> 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 man
on initial 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" wrote:
> Hi Alex,
>
> On Fri, 2015-03-20, at 14:52, Alex Bowers wrote:
>
> > But I don't think we should only match
On 20 March 2015 at 16:17, Leigh 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.
RFC.
On 20 March 2015 at 16:17, Leigh wrote:
>
> On Mar 20, 2015 4:00 PM, "Alex Bowers" 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
> string
>
> 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?
>
> 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 order dependant
whilst using the associated keys isn't correct in my view.
On 20 March 2015 at 14:41, Rowan Collins 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&#x
>
> 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.
Good day,
My Wiki username is: alexbowers
I have an RFC currently under gauge within the thread (link:
https://marc.info/?l=php-internals&m=142679821024794&w=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,
A
mentation pages provided
and clear naming for the differences between them.
On 20 March 2015 at 13:21, Rowan Collins wrote:
> Alex Bowers wrote on 20/03/2015 13:10:
>
> $array['x':'z'] = []; // Remove all elements with keys between 'x' and
>> 'z&#
>
> 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 [] fo
t by index) which should be a separate RFC thread, assuming this one
gets accepted to be expanded upon.
On 20 March 2015 at 13:04, Rowan Collins wrote:
> Alex Bowers wrote on 20/03/2015 12:32:
>
>> We also need to consider then the possibility of setting data by position.
>>
&
On 20 March 2015 at 13:04, Rowan Collins 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?
>
> 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!
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?
>
> 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 bee
>
> 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 t
>
> 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
>
> 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
On 19 March 2015 at 23:23, Rowan Collins wrote:
> On 19/03/2015 20:49, Alex Bowers wrote:
>
>> My proposal is something similar to Pythons slice, in PHP this would look
>> like:
>>
>> $slided = $array[1:4]
>>
>> This will get the elements in
On 19 March 2015 at 21:11, Larry Garfield 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 lis
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 wrote:
> On 3/19/15 3:49 PM, Alex Bowers wro
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),
igno
56 matches
Mail list logo
