On Tue, Jun 25, 2024 at 1:56 AM Bilge wrote:
> Hi Alex,
>
> If you wish to implement data objects, what part of the current proposal
> precludes you from doing so?
>
>
None, but they both try to solve the same problem, so it's highly unlikely
that data objects would eve
Hey Bilge,
I'm not usually a resident of these discussions, but it seems like this RFC
is heading into a wrong direction. Let me explain: as it currently stands,
static properties and methods live separately from instance properties and
methods. That means a couple of limitations, namely: a static
On Fri, Apr 26, 2024 at 11:01 AM Benjamin Außenhofer
wrote:
> After discussing with Mate shortly one reason for adding $since from a PHP
> project POV is that we do show the $since information in the generated
> documentation output.
>
> Integrating with the work in progress to auto generate part
On Wed, Apr 10, 2024 at 4:01 PM Erick de Azevedo Lima <
ericklima.c...@gmail.com> wrote:
> Maybe if such a feedback was given before and it was decided to go for a
> trimmed version of the feature, maybe Ilija/Larry could have had less work
> to implement and test all the variantes they've done. I
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
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?
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, k
quirements. Sometimes,
any project requires big changes to move forward. I'm pretty sure this
functionality will move PHP to the next level and expand its area of
applications. My thoughts here are mostly from the user's perspective, I'm
not so familiar with PHP internal implementation. But I think this feature
can be a good goal for PHP 9.
--
Best regards,
Alex Pravdin
On Fri, Nov 10, 2023 at 1:33 PM Craig Francis
wrote:
> On 10 Nov 2023, at 10:54, Alex Wells wrote:
>
> PHPStan does find them:
> https://phpstan.org/r/38fc1545-2567-49b9-9937-f275dcfff6f5
>
>
>
> It does not:
>
> https://phpstan.org/r/c533ff42-80e4-4309-975
On Fri, Nov 10, 2023 at 12:47 PM Craig Francis
wrote:
> This will start getting Fatal Type Errors in 9.0... and finding these
> "mistakes" is close to impossible (phpstan doesn't find them; psalm
> requires high levels 1-3)
>
PHPStan does find them:
https://phpstan.org/r/38fc1545-2567-49b9-9937-
On Wed, Oct 18, 2023 at 2:37 PM Pierre wrote:
> Le 18/10/2023 à 13:01, Alex Wells a écrit :
> > The community has just now decided on the PHPDoc syntax for generics,
> has
> > just started widely adopting them in packages and has just got
> first-party
> > support
On Tue, Oct 17, 2023 at 10:40 PM Rowan Tommins
wrote:
Using the same syntax for type information that is guaranteed to be true
> (existing run-time checks) and type information that is "advisory only"
> (new checks for optional static analysis) means users can no longer have
> confidence in that
On Mon, Oct 16, 2023 at 5:08 PM Olle Härstedt
wrote:
> Hello internals,
>
> Was there a previous discussion about the pros/cons of adding only the
> syntax needed for generics, but not the functionality? So static
> analyzers could use it, instead of docblocks. I looked at externals.io
> but coul
On Wed, Apr 12, 2023 at 7:31 PM Stanislav Malyshev
wrote:
> If learning a couple of very simple rules is too much for you, maybe you
> are too busy to take on yourself another responsibility such as
> participating in PHP development. Encouraging drive-by commentary is not
> something that is a g
On Wed, Apr 12, 2023 at 6:15 PM Pierre wrote:
> That was my 2 cents about all this. Maybe what the thread creator mean
> is simply that the PHP development process is kind of hidden in this
> list, and it's not that easy to reach or read for people, even when
> using https://externals.io/
Pierr
On Wed, Apr 12, 2023 at 5:16 PM Rowan Tommins
wrote:
> I think "moving to a modern platform" presents a false dichotomy.
>
> Any move needs to be assessed on both the advantages and disadvantages of
> *both* (or all) options, not just what looks new and shiny if we move.
>
> Some starting points
On Wed, Apr 12, 2023 at 5:09 PM Alain D D Williams
wrote:
> * Archives: already done
It is; however, there's no way to categorize it (except for creating even
more mailing lists), tag it, mark as resolved, close it or basically do
anything other than write a message.
> * Not way of editing: j
On Wed, Apr 12, 2023 at 4:57 PM Marco Pivetta wrote:
> FYI: https://externals.io/message/87501#87501
>
> Also: wow, that was 7 years ago?! :O
>
Thanks. I've completely missed this while searching for an alike thread :)
But as you mentioned, it's been 7 years. Many things and people have
changed
Hey.
PHP currently uses internals@lists.php.net for communication. That includes
mostly RFCs (or their votings, or their pre-discussion) and sometimes
questions about the implementation or possible bugs.
While emailing definitely works, it's not the best UX out there. Here are
some immediate flaw
On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote:
> I don't want to use those weird stuff, but I'm
> doing the best I can to replace every single line of old code that has been
> written in an era that "best practices for PHP development" were not what
> you and I know today.
>
I still do not underst
On Mon, Apr 10, 2023 at 3:59 PM Craig Francis
wrote:
> One team of developers I know are still finding these issues well over a
> year later (they also introduce new code that trips it as well); two other
> teams specifically ignore this deprecation (far too many instances to
> "fix"), and one te
On Mon, Feb 27, 2023 at 5:09 PM Clint Priest wrote:
>
> On 2/13/2023 4:13 AM, Arvids Godjuks wrote:
> > Good day dear Internals!
> >
> > I've been following this thread/RFC from its inception to the current
> > moment. I have watched the situation deteriorate and at this point, I
> have
> > major
On Wed, Jan 18, 2023 at 10:09 PM Claude Pache
wrote:
>
>
> Le 18 janv. 2023 à 19:33, Alex Wells a écrit :
>
> Classes and methods is the expected way of implementing standard library
> in an OO language. New APIs (such as the new Random api) use OO instead of
> functions an
On Wed, Jan 18, 2023, 19:57 Claude Pache wrote:
>
>
> > Le 18 janv. 2023 à 18:27, Kamil Tekiela a écrit :
> >
> > Strings should not be incrementable unless they are numeric strings. The
> > current "feature" is more like a bug from xkcd comic.
> https://xkcd.com/1172/
> >
> > But as there is a
> On 12 Oct 2022, at 11:06, Jordan LeDoux wrote:
>
> If a "preview" doesn't allow us to make breaking changes, then what exactly
> is the point? I don't see any benefit at all to this without that.
>
> If the "preview" is *actually* just "put out an RFC in the next patch
> release as soon as i
> On 11 Oct 2022, at 15:24, Christian Schneider wrote:
>
> We seem to have two different views on experimental feature here: You are
> saying they could get removed again while others stated it is for stuff which
> will definitely end up in stable when the next major release is done.
An exper
> On 7 Oct 2022, at 18:44, Larry Garfield wrote:
>
> On Fri, Oct 7, 2022, at 5:58 AM, G. P. B. wrote:
>> On Fri, 7 Oct 2022 at 07:57, Christian Schneider
>> wrote:
>>
>>> But now to my main point: You are talking about the most simple and
>>> isolated case, a new function.
>>>
>>
>> I agre
> On 6 Oct 2022, at 23:12, Rowan Tommins wrote:
>
> On 06/10/2022 17:41, Alex Wells wrote:
>> For example, Kotlin has recently introduced a new feature - unsigned integer
>> types.
>
>
> I'm still struggling to understand what I, as a user, would do ab
> On 6 Oct 2022, at 16:06, Rowan Tommins wrote:
>
> On 06/10/2022 12:16, Alex Wells wrote:
>> A marker merely just tells the compiler "hey, allow me to use this feature
>> right here", i.e. it denotes a piece of code as allowed to use the feature,
>
> On 6 Oct 2022, at 15:26, Christoph M. Becker wrote:
>
> On 04.10.2022 at 22:42, David Rodrigues wrote:
>
>> I wanted to suggest the possibility of introducing experimental features to
>> PHP.
>>
>> This is an old thread I guess, but I think it's good to reevaluate the
>> situation from tim
> On 5 Oct 2022, at 20:41, Rowan Tommins wrote:
>
> On Wed, 5 Oct 2022 at 18:07, David Rodrigues wrote:
>
>> Another advantage in this sense is that it would be possible to have a
>> single development branch for PHP 8.1 (current version) and 8.2
>> (development version), for example, with t
Hey.
Experimental features have been briefly discussed before in
https://github.com/PHPGenerics/php-generics-rfc/issues/49. I believe this
is a good starting point to understand how it's different to extensions or
otherwise different builds of PHP.
Advantages of experimental features over extensi
> On 11 Aug 2022, at 22:02, Larry Garfield wrote:
>
> On Thu, Aug 11, 2022, at 1:59 PM, Alex Wells wrote:
>
>>>> Well, pipe operator is another option, but it’s got it’s downsides
>>>> compared to extension methods:
>>>> - it's less v
> On 11 Aug 2022, at 21:58, Larry Garfield wrote:
>
> On Thu, Aug 11, 2022, at 1:51 PM, Alex Wells wrote:
>
>> The pipe operator RFC has actually been mentioned before; the short
>> takeway is: pipe operator works and has a benefit of using existing
>> functio
> On 11 Aug 2022, at 21:42, Larry Garfield wrote:
>
> On Thu, Aug 11, 2022, at 4:03 AM, Alex Wells wrote:
>
>> Besides, I believe working with existing functions is more of a problem
>> than a bonus - because of the naming. You’d have to clutter your code
>>
> On 11 Aug 2022, at 17:25, Christian Schneider wrote:
>
> Am 11.08.2022 um 11:03 schrieb Alex Wells :
>> That’s just a concept. I’d love to bring a lot more examples in an RFC if
>> there’s more positive than negative feedback. Again, I’m more looking for
>&
> On 11 Aug 2022, at 18:10, Rowan Tommins wrote:
>
> On 11/08/2022 10:03, Alex Wells wrote:
>> You could argue the problem is that all of these are single-liners, so here
>> are the same examples, but multiline formatted:
>
>
> When people talk about avoidin
> On 11 Aug 2022, at 07:36, Paul Crovella wrote:
>
> This isn't impossible. There's nothing stopping an IDE from seeing
> `$collection->` and suggesting/completing that with `map($collection, ` -
> they just don't right now. Offhand I don't see why this would be more
> difficult for them to
> On 11 Aug 2022, at 00:30, Rowan Tommins wrote:
>
> a class implementing __call is assumed to reserve *all* method names.
This does make sense. Either an extension has precedence over class methods or
it does not; having extension methods in the middle of statically defined
methods and __cal
Thanks for explaining it better than I did.
Regarding the implementation, that was roughly what I was thinking.
But can't we put extension methods second, after real methods but before
__call? As far as I understand, the reason to put it after __call is to
avoid a performance penalty on __call ca
se, unless you attempt to import both of them in a
scope of one file.
On Wed, Aug 10, 2022 at 7:18 PM Ben Ramsey wrote:
> On 8/10/22 09:17, Alex Wells wrote:
>
> > The idea is to introduce extension methods, similar to those in Kotlin,
> C#,
> > Dart. For those unfamilia
I believe disallowing multiple extensions on one type defeats one of
the purposes of the feature - extending from outside. Let's say you have a
vendor package for manipulating strings which defines an extension on
`string` type. It works, but then you need one more custom extensions -
some kind of
Hey internals.
The idea is to introduce extension methods, similar to those in Kotlin, C#,
Dart. For those unfamiliar, those are just regular functions with fancy
syntax. However, I think having those will not only improve readability,
but also cover some of the previously requested features.
Say
I like it!
What is the $use_flags parameter for?
On Sat, Aug 29, 2020 at 10:24 PM tyson andre
wrote:
> Hi internals,
>
> The primitives any() and all() are a common part of many programming
> languages and help in avoiding verbosity or unnecessary abstractions.
>
> -
> https://hackage.haskell.o
rting from scratch.
- If you are still struggling, run your test under gdb so you can get a
stack trace when it segfaults. It's as simple as "gdb --args ". Make sure that both the PHP embed SAPI and your own test
code were compiled with debug info enabled.
Alex
On Wed, Aug 26,
I guess the first question is: Why is it so slow? I don't think that using
shared memory to store data is inherently slower than storing it anywhere
else.
It might be that spending an hour or two profiling and optimizing could
slash this time right down.
On Wed, Aug 26, 2020 at 9:37 AM Nikita Pop
Dear Levi Morrison, please see this added test case:
https://github.com/php/php-src/pull/5384/files#diff-dc4d304baf106b4a30432f80dae1a538
The iteration behavior of the modified SplFixedArray is quite humane
even in the face of changing array size.
--
PHP Internals - PHP Runtime Development Maili
Dear Levi, I will add a test case to the PR to ensure that things work
properly in the described situation.
On Fri, Jun 26, 2020 at 3:57 PM Levi Morrison
wrote:
>
> On Fri, Jun 26, 2020 at 12:45 AM Alex wrote:
> >
> > Dear PHP Internals,
> >
> > I would like to pr
hem. This may break a few
users' code, but in a way which will be easier for them to debug than
if the old methods were kept but subtly changed in behavior.
Code to implement this change is here:
https://github.com/php/php-src/pull/5384/files
Your comments will be appreciated,
Alex Dowad
-
> Why is there a 15 byte limit in the first place?
Presumably it might be so that multi-megabyte strings are not dumped
to the console when printing out a stack trace. (Disclaimer: I have
not touched the relevant code and am just guessing.)
--
PHP Internals - PHP Runtime Development Mailing List
feel each one should really "carry its weight". But if
this one does, that is fine.)
Alex
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Maybe it would be good to talk to the developers of that package? They
might have some valuable input on how to design a built-in `enum`
feature.
It might also help them plan out a migration path.
On Mon, Jun 15, 2020 at 11:18 AM Ilija Tovilo wrote:
>
> Hi Marco
>
> >> I created a new RFC for r
Edit/close tickets in the bug tracker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.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 "]
[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.
by a quick search on
the wiki.php.net/rfc page.
Thanks.
Alex.
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
On 2016-05-31 22:15, Jesse Schalken wrote:
Hi internals,
I often have code dealing with plain old PHP objects with properties and no
methods, either as a substitute for keyword arguments, or to represent a
JSON or YAML document for a web service, configuration file or schemaless
database.
At th
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
t
behavior.
-alex
On Wed, Oct 14, 2015 at 11:59 PM, Björn Larsson
wrote:
> Den 2015-10-14 kl. 21:25, skrev Sammy Kaye Powers:
>
>> Hello internals friends!
>>
>> I'd like to open a discussion on the RFC to allow trailing commas in
>> function arguments.
>>
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.
Thanks,
Alex.
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.
>>
&
1 - 100 of 214 matches
Mail list logo
