Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist
Discussions should remain on the list.
Any
wt., 16 cze 2020 o 09:50 Nikita Popov napisał(a):
> On Tue, Jun 16, 2020 at 8:59 AM Mike Schinkel wrote:
>
> > Hi internals,
> >
> > Given that there appears to be some appetite to reduce checks for
> > inappropriate signatures[1] I am wondering if anyone has strong opinions
> —
> > pro or con —
Hi Mike,
wt., 16 cze 2020 o 08:59 Mike Schinkel napisał(a):
> Hi internals,
>
> Given that there appears to be some appetite to reduce checks for
> inappropriate signatures[1] I am wondering if anyone has strong opinions —
> pro or con — on removing checks for static methods?
>
> My primary use-
wt., 9 cze 2020 o 13:56 Benjamin Eberlei napisał(a):
> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown
> wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback complete
wt., 9 cze 2020, 15:33 użytkownik Nikita Popov
napisał:
> On Tue, May 12, 2020 at 10:26 AM Nikita Popov
> wrote:
>
> > On Wed, Mar 11, 2020 at 10:50 AM Nikita Popov
> > wrote:
> >
> >> Hi internals,
> >>
> >> Userland classes that implement Traversable must do so either through
> >> Iterator or
śr., 3 cze 2020 o 09:49 Michał Brzuchalski
napisał(a):
> pt., 22 maj 2020 o 08:14 Michał Brzuchalski
> napisał(a):
>
>> Hi Internals,
>>
>> We have just opened the vote on the PHP namespace in core RFC. The voting
>> will be
>> open for two weeks, until 20
pt., 22 maj 2020 o 08:14 Michał Brzuchalski
napisał(a):
> Hi Internals,
>
> We have just opened the vote on the PHP namespace in core RFC. The voting
> will be
> open for two weeks, until 2020-06-05 06:00 UTC.
>
Heads-up. We will end the vote soon.
If anyone may have not de
Hi Internals,
We have just opened the vote on the PHP namespace in core RFC. The voting
will be
open for two weeks, until 2020-06-05 06:00 UTC.
Link: https://wiki.php.net/rfc/php-namespace-in-core#vote
Cheers,
Michał Marcin Brzuchalski
always.
Voting will open Tomorrow on *May 22nd around 06:00 UTC*
and will remain open for 14 days until *4th of June.*
Cheers,
--
Michał Marcin Brzuchalski
/For the fame and glory of PHP!!/
śr., 15 kwi 2020 o 14:29 Michał Brzuchalski
napisał(a):
> Hi internals,
>
> I hope you'r
PHP.
I've never used it and actually was asking myself why is it in the core.
I would vote for unbundling of it.
Cheers,
Michał Brzuchalski
int for
callable/closure check
but actually this is not the case we're looking for. Things where mentioned
delegate
match perfectly is the places where your expectations to the
callable/closure type
are static and known at the time when writing code.
Given that in a situation when the input and the output types are known
this would bring the benefit of runtime check before use.
Cheers,
Michał Brzuchalski
a
good idea as a way to provide
callable types checking.
Any thoughts are highly appreciated!
Cheers,
Michał Brzuchalski
Hi Benjamin,
pon., 20 kwi 2020 o 14:06 Benjamin Eberlei napisał(a):
> Hi Michał, George,
>
> On Wed, Apr 15, 2020 at 2:29 PM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> Hi internals,
>>
>> I hope you're doing well.
>>
>
namespace in the core
for tightly coupled to the PHP engine types
which could be placed there without a risk to be unbundled in a future what
would cause a need to rename them back.
Therefore we think that these along with the arguments in the proposal are
the best ones to agree for now.
BR,
Michał Brzuchalski
7;m just
> explaining that a different expectation exists, and why)
>
>
Agree this would slow things down but if it could be potentially type
checked on the assignment with type constraint in front of the variable
name I think that would be a neat feature.
So to work as a function parameter but not like a typed property.
Cheers,
Michał Brzuchalski
sible to write:
int $id = $data['id'];
int $id = getIdFromData($data);
And then expect the $id to behave more like typed property with type guard.
At least this is me what would expect from putting a type in from of
variable name
like in array destructuring example.
Why? Cause it has a type constraint in from of variable name just like
typed properties have.
Cheers,
Michał Brzuchalski
Hi Derick,
śr., 15 kwi 2020 o 15:51 Derick Rethans napisał(a):
> On Wed, 15 Apr 2020, Michał Brzuchalski wrote:
>
> > Hi internals,
> >
> > I hope you're doing well.
> >
> > I'd like to announce the PHP Namespace in core RFC for discussion.
>
ge Peter Banyard and it's
> > purpose
> > is nothing more like to allow the use of PHP Namespace in the core.
> >
> > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core
> >
> > Best Regards,
> > Michał Brzuchalski
>
> Hello,
cribed at https://wiki.php.net/rfc/php-namespace-in-core
Best Regards,
Michał Brzuchalski
onna download the php-src source code,
build environment and go with the ext/standard implementation and start
adding it in C.
The notice in this cases should either be different or not emitted at all.
If the latter then that has to be documented I guess.
Cheers,
--
Michał Brzuchalski
always verbose and easy to read/decipher
this solution IMHO has more drawbacks regarding readability than benefits.
Cheers,
--
Michał Brzuchalski
();
>
> baz()
>
> },
>
> };
>
> ```
>
>
>
> This is indeed possible in PHP and could be implemented as part of the
> `switch` expression or as a general language feature. A nice side effect is
> that this could also be used in arrow functions:
>
>
>
> ```php
>
> $x = fn() => {
>
> foo();
>
> bar();
>
> baz()
>
> };
>
> ```
>
>
>
> This would, however, make it inconsistent with closures as they use the
> return keyword. Thus we would probably have to make sure arrow functions
> still work with return statement which would decrease the need for such a
> language construct. It is also very unlike anything else in PHP.
>
>
>
> # Poll
>
>
>
> This is a short overview of what I'll be working on in the coming weeks. I
> created a short poll for you guys to let me know if this idea is worth
> pursuing:
>
> https://forms.gle/stXMv72CAaDDxfwf8
>
>
>
> Stay safe!
>
>
That looks like what I've described a few months ago in
https://wiki.php.net/rfc/switch-expression-and-statement-improvement
If you dig into the mailing list you can even find almost ready to use
patch which implements it.
I'd love switch expression inclusion in PHP.
Cheers,
Michał Brzuchalski
; > * Constructor Promotion
> > I would vote yes on this, assuming the implementation is sane.
>
> On Mon, Mar 23, 2020, at 12:55 AM, Michał Brzuchalski wrote:
>
> > That still doesn't resolve issue with lot of boilerplate when you deal
> with
> > small objects fo
Hi Larry,
pon., 23 mar 2020, 01:48 użytkownik Larry Garfield
napisał:
> Hi folks.
>
> There have been a lot of RFCs and possible RFCs of late that are all
> circling around the same related problem space: Working with objects right
> now involves too much boilerplate to get things done. As I've
śr., 18 mar 2020, 03:36 użytkownik Jakob Givoni napisał:
> Thank you, Michał, for chiming in :-)
>
> On Tue, Mar 17, 2020 at 10:52 AM Michał Brzuchalski
> wrote:
> > For object initializer, I was hoping to introduce a feature which with
> the benefits of typed properties
es and it looks like they could be also marked as
read-only in next major PHP version.
Cheers,
--
Michał Brzuchalski
they do have a public __construct
so they look like classes but are not actually classes which you should be
allowed to instantiate wherever
you want, right? So we agree it looks a little weird here but dunno if
there's something we can do.
cheers,
Michał Brzuchalski
27;t we go with Token class name alone without the prefix?
The only one which includes PHP in class names so far are only:
* __PHP_Incomplete_Class
* php_user_filter
Above taken from https://www.php.net/manual/en/reserved.classes.php
BR,
Michał Brzuchalski
wt., 11 lut 2020, 21:14 użytkownik Dik Takken
napisał:
> On 11-02-2020 20:01, Michał Brzuchalski wrote:
> > wt., 11 lut 2020, 18:42 użytkownik Manuel Canga
> > napisał:
> >
> > That reminds me an old draft RFC https://wiki.php.net/rfc/short-closures
> > where I
familiar alternatives should be
> explored as well. Thinking about the existing list() and array() syntax,
> another possibility could be:
>
> closure(foo);
> closure($obj->Fot);
> closure(Zoq::Fot);
>
It looks like a function but it's not a function cause what you have inside
parentheses looks like a const, property and class const.
IMO a statement like that for consistency it should be with no parentheses
like:
$foo = closure foo;
$foo = closure $obj->Fot;
$foo = closure Zoq::Fot;
Cheers,
--
Michał Brzuchalski
>
allable(['Zoq',
> 'Fot']);
>
> to
>
>
> <$foo, Fot>
>
>
>
> E.g:
>
> array_map(, $array);
> array_map(, $array);
>
> Do you like ?
>
That reminds me an old draft RFC https://wiki.php.net/rfc/short-closures
where I thought curly braces can be used to create closure from syntax
nearly the same as invoking but without parentheses.
That way we can provide clear intent - I mean if whatever is around: curly
braces or $ with parentheses IMHO it should be consistent with call like
format. For example:
$(strlen) or {strlen} for Closure::fromCallable('foo')
$($foo->Fot) or {$foo->Fot} for Closure::fromCallable([$obj, 'Fot'])
$(Zoq::Fot) or {Zoq::Fot} for Closure::fromCallable('Zoq::Fot')
Etc. The same inside like a call but wrapped in something and with no
parentheses part.
Cheers,
--
Michał Brzuchalski
>
t", "throw" etc.
> Potential alternatives would be Stringifyable (or Stringifiable?),
> StringCastable, StringConvertible...
> (Even though I personally have no problem with "Stringable")
>
>
Maybe StringObject? We do already have ArrayObject.
BR,
--
Michał Brzuchalski
stead of ServerRequest instance properties and a single point to retrieve
header values just like
well known ParameterBag's from HttpFoundation to operate on get, post,
headers etc.
BR,
--
Michał Brzuchalski
Fatal error: Uncaught
Error: Cannot unset string offset".
An expected result is to be the same but an effect radically different as
you can see [1].
IMHO allowing string offset to be unset using unset construct could be
allowed to ensure consistency then.
Any thoughts on this?
BR,
--
Michał Brzuchalski
[1] https://3v4l.org/0Ol3N
hat accepts is countable (look at generators).
speaking of arrayable probably you're thinking of counting it too, but then
it would require to behave like an intersection of types
arrayable = iterable&countable - going further it would not accept
generators anymore - concluding people would still use iterable
and not arrayable for traversing using foreach etc.
Just my 50cents.
Cheers,
Michał Brzuchalski
Cheers,
Michał Brzuchalski
pon., 7 paź 2019 o 13:00 Michał Brzuchalski
napisał(a):
> Hi all,
>
> the discussion period was long and discussion I think quite comprehensive.
>
> The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
> voting now.
> The voting
my proposal with commas, see here:
https://wiki.php.net/rfc/switch-expression-and-statement-improvement#switch_expression_introduction
Unfortunately, this RFC needs more work cause it mixes switch statement
enhancement with comma-separated list syntax and of switch statement - I
need to split it into two RFC's
This is nice hearing that this idea has an interest.
As soon as the RFC will be split and finished I can start a discussion
thread.
Cheers,
Michał Brzuchalski
witch-expression-and-statement-improvement
Cheers,
Michał Brzuchalski
śr., 16 paź 2019, 03:46 użytkownik David Rodrigues
napisał:
> Hello. I like to suggests a discussion about a FR to make possible to
> inline switch, as an alternative to nested inline conditionals.
>
> $val
; anything reflection-ish based.
>
Thank you for your feedback.
Cheers,
Michał Brzuchalski
Hi all,
A follow-up note.
There is no implementation of a patch yet.
BR,
Michał Brzuchalski
pon., 7 paź 2019 o 13:00 Michał Brzuchalski
napisał(a):
> Hi all,
>
> the discussion period was long and discussion I think quite comprehensive.
>
> The RFC is at https://wiki.php
Hi all,
the discussion period was long and discussion I think quite comprehensive.
The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
voting now.
The voting will take 2 weeks from 11:00 UTC 7th till 11:00 UTC 21st of
October 2019.
BR,
Michał Brzuchalski
Hi all,
the discussion period was long and discussion I think quite comprehensive.
I'd like to open the RFC up for a voting today at 11:00 UTC. The voting
will take from 11:00 UTC 7th till 11:00 UTC 21st of October 2019.
BR,
Michał Brzuchalski
czw., 12 wrz 2019 o 16:00 Michał Brzuch
this from class
inner scope exactly the same way as you're able to access them from class
inner scope now.
This feature may not be a cure for all diseases, but I believe is the right
to reduce noise and boilerplate when instantiating and initializing simple
objects with type restrictions and ensures valid object state every time
it's used.
BR,
Michał Brzuchalski
ut being redundant.
>
Sorry for that, the quoted sentence was left unintentionally and yes, it's
not off-topic.
Had to rethink what I was trying to say, but I do think both these features
could exist.
Regards,
Michał Brzuchalski
Hi Rowan,
pon., 16 wrz 2019 o 15:47 Rowan Tommins
napisał(a):
> On Mon, 16 Sep 2019 at 08:29, Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> > Please keep in mind that initializing properties through object
> initializer
> > applies to visible
Hi all,
czw., 12 wrz 2019 o 16:00 Michał Brzuchalski
napisał(a):
> Hi internals,
>
> I'd like to open discussion about RFC: Object Initializer.
>
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without require
Hi Paul,
niedz., 15 wrz 2019 o 15:48 Paul M. Jones napisał(a):
>
>
> > On Sep 12, 2019, at 09:00, Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
> >
> > Hi internals,
> >
> > I'd like to open discussion about RFC: Object Initial
tomatically called
> after __construct():
>
>
Thank for your feedback and ideas, but I decided not to include it in the
RFC.
Thanks in advance,
Michał Brzuchalski
country = "GB",
phoneNumber = PhoneNumber::fromString("+1555 010 020"),
birthDate = new DateTimeImmutable("1983-01-01"),
email = Email::fromString("john@example.com"),
};
}
Thanks in advance,
Michał Brzuchalski
eanings: { foo = 10 }
>
>
>
{ $foo = 123 }; // unexpected "}" cause of missing ";"
$bar = { $foo = 123 }; // unexpected "{" cause it's not allowed in this
context
Both examples are syntax error.
You can use {} for separating blocks of code, but now if you wanna assign
value.
Everything considered syntax error can be used for feature shaping.
Regards,
Michał Brzuchalski
reason about choosing "=" was a simplification of instantiation and
properties initialisation
and we use "=" to assign property values now.
The "=>" is specific for array key pairs and IMO should stay specific for
arrays only.
Thanks,
Michał Brzuchalski
g `{ foo = 10 }` create an `stdClass` object (not
> in the RFC); While not used much since it has no effect, it's perfectly
> okay to put your code in brackets eg `{ { { $foo = 10; } } }`. As such, I
> don't think it's a good idea to allow `new stdClass` to be omitted.
>
Future scope mentions only about letting to create stdClass with omitting
of the class name only,
nothing said about removing a new keyword.
Thanks,
Michał Brzuchalski
Hi Claude,
pt., 13 wrz 2019 o 08:39 Claude Pache napisał(a):
>
>
> Le 13 sept. 2019 à 07:49, Michał Brzuchalski
> a écrit :
>
> Hi Lynn,
>
> czw., 12 wrz 2019 o 17:01 Lynn napisał(a):
>
> Heya,
>
> What's the added benefit of this compared to implement
n more strikes but that's
not the main reason about that RFC - nice to have but let's start with
something.
Regards,
Michał Brzuchalski
tax which would
not be restricted to stdClass only.
Although it's not a game-changer, simple addition to the language which
reduces boilerplate when dealing
with objects which don't need complex constructors like for eg. DTO objects.
Regards,
> Lynn van der Berg
>
>
Regards,
Michał Brzuchalski
t/rfc/object-initializer
I appreciate any feedback you all can provide.
Thanks,
--
Michał Brzuchalski
brzuc...@php.net
idea and we should not change the way comments work
especially inline comments which even aren't kept in opcache.
I think better approach would be to put type in front of first variable
declaration like:
[type] $variable = $value;
BR,
--
Michał Brzuchalski
śr., 14 sie 2019 o 12:17 Michał Brzuchalski
napisał(a):
>
>
> śr., 14 sie 2019 o 12:11 Rowan Collins
> napisał(a):
>
>> On 14/08/2019 11:07, Michał Brzuchalski wrote:
>> > Exactly so how would it know from string name either it should load
>> class
>>
śr., 14 sie 2019 o 12:11 Rowan Collins napisał(a):
> On 14/08/2019 11:07, Michał Brzuchalski wrote:
> > Exactly so how would it know from string name either it should load class
> > from src/Foo.php or src/__nsmeta.php if there is no information?
>
>
> It wouldn't.
ot;. The userland part of the
> autoloader already doesn't know which of those it's looking for, so the
> only constraint is that the names can't collide, so you couldn't name a
> package the same thing as a class.
>
>
Exactly so how would it know from string
śr., 14 sie 2019 o 11:01 Rowan Collins napisał(a):
> I don't see this as a problem. Right now, PHP doesn't care how many
> files you put your code in. As far as I know, you could concatenate the
> entirety of Laravel into one PHP file, and applications would not be
> able to tell the difference.
mix normal PHP code with package definition,
cause every possible PHP syntax
we would agree, opens the door to add something more to that file, for eg.:
# package.php
https://wiki.php.net/rfc/namespace_scoped_declares#motivation_and_vision
[2] https://www.php.net/manual/en/function.register-tick-function.php
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
t we should
> not ignore.
>
I did some writings on that
https://brzuchal.com/posts/packages-in-programming-languages/ was a little
hurry
but tried my best to grasp key aspects of package / module concept in other
languages.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
k a package and declare an unrelated file as part
> of it, but I don't think that's an issue: the situation is the same as for
> namespaces, where one can hijack a third party vendor namespace. In
> practice, it proved not being an issue, and the original author's intent is
> clear: "this is my namespace/package, if you mess with it, fine, but you're
> on your own".
>
> Nicolas
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
Hi Zeev,
pt., 9 sie 2019, 14:23 użytkownik Zeev Suraski napisał:
>
>
> On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> Hi Sergey,
>>
>> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev > >
>&
Hi Sergey,
pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev
napisał:
> As I understand, in P++ it was planned to drop the legacy code, add new
> functionality and painlessly implement BC.
>
> Who wants – migrates the PHP project in P++, who doesn't – continues to
> use PHP.
>
> New projects, f
m pretty sure I've mentioned that earlier.
If we wanna shape package for PHP then the separate discussion could be a
good idea.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
le => Symfony\Component\Console\
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
e boundaries of
namespace scope
or package scope (whatever you call that) symbols without a root namespace
file.
I can imagine some can use explicit require to load library class to skip
scoped declares,
autoloads or whatever lands there.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
or
> (Foo) +$bar, etc.
>
Wouldn't that be possible to differentiate consts with class names if we
merge symbol tables and allow only one symbol with the same name?
I know this is huge BC break but AFAIK in the past, there was a discussion
about merging symbol tables.
--
regards / pozdr
hat, either way, we're
delivering feature
which has very limited usage which can be confusing, cause I can
array_merge or
use + operator so why can't I use keys with spread operator if I already
have them in
my generator, iterable or array which came from for eg. json_decode or
whatever.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
_operator_for_array#string_keys
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
pt., 5 kwi 2019 o 08:56 CHU Zhaowei napisał(a):
> Here is a MDN document for spread operator in JS:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_array_literals
> and hope you find more useful examples.
>
The next paragraph in MDN document
Hi CHU Zhaowei,
Where can I find first RFC version? Revisited RFCs AFAIK should be served
under different name.
Personally I liked key preserve behavior. Without it use of spread operator
I array expression would have minor use. But this is my personal feeling
about only.
I think I'm missing som
2]
>
>
> In general, I see two alternatives:
>
> 1) Pass short closures and then include a special case of that special
> case that effectively gives us comprehensions over foreach, if, and yield,
> but with fewer seemingly-stray characters.
>
> 2) Steal a completely different syntax from some other language that is
> still terse but less confusing. The main alternatives to "square brackets
> around a for loop" syntax seem to be:
>
> A) Chained filter() and map() methods
> B) SQL-like keywords
> C) Use <- somehow.
> D) Use a different starting character before the [] so that the parser
> knows some new funky order of stuff is coming.
>
> I am open to both options, of course contingent on someone willing and
> able to code it.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
Great work and I like the idea in general.
BR,
--
Michał Brzuchalski
List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
mming-languages/year-2019/
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
gt; booleans) (wich may be defined with % character)
>
> %string = 'abcde';
> %integer = 123;
> %floating = 1.23;
> %boolean = true;
>
> The remaining types(callables, resources), I suppose, should continue to
> store in variables. New characters for our new entities will be discussed
> further in RFC.
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
r the specific error type is
> > silenced.
> >
> > A preliminary patch for this change is available at
> > https://github.com/php/php-src/pull/3685.
> >
> > What do you think about this?
> >
> > Nikita
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
arameters#future_scope
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
śr., 27 cze 2018 o 16:55 Michał Brzuchalski
napisał(a):
>
>
> śr., 27 cze 2018 o 03:29 Rudolf Theunissen
> napisał(a):
>
>> > I would like to see this in an extension first, i think it's perfectly
>> doable and people can test it before merging to cor
f the two magic methods in the operands.
> >
> > - I'd introduce a debug mode that forces php to call both
> > $left->__equals($right) and $right->__equals($left) so that symmetry is
> > guaranteed by design. You could do that when "assertions" are active.
> >
> > gl
> >
>
[1] https://github.com/php/pecl-php-operator/blob/master/operator.c
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
gt; like `array_search`. The question we're asking is whether the two values
> are
> considered equal, and we're not concerned with ordering. The context for
> comparison is when we need to determine the relative ordering of two values
> using `<`, `>`, or in fu
;
> This may change periodically.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
omparison=1);` be easier for those who prefer strict
everywhere?
We have `declare(strict_types=1);` so we may have stricter declares also.
Maybe someday it turns into a standard way of working with PHP and can get
rid of declares without any code changes.
This may result in all comparisons strict wit
; Now, I got your idea.
>
> Subclassing CData, and use that types for type hinting may make sense.
>
> I'll put this idea in my TODO, but with low priority.
>
>
> Thanks. Dmitry.
> ------
> *From:* Michał Brzuchalski
> *Sent:* Tuesday,
, thats why I thought it would be usefull.
I could then prepare a vendor using pure PHP and wrap everything using
types.
>
> I'll think, if we can existend API to use something like: $tz =
> FFI::new($libc->timezone);
>
> At least, this should eliminate C parsing overh
resources are involved), otherwise we leak state between
> requests.
> - OTOH, people may want to load a set of persistent definitions from a
> config file, etc. - the ffi definition probably won't change much, and
> having locked down set of FFI interfaces the rest of the co
tion.
>
> There are reasons not to do that and use a separate flag for one or both of
> these methods. While I can live with that I would like to point out that
> debug flag proliferation can lead to confusion.
>
> The crux of my argument for using the zend.assertion flag is that these
> type checks are all, at the end of day, engine level assertions. PHP ships
> with zend.assertion set to 1, and with PHP 8 we can keep that default and
> recommend to providers to not assume it's safe to set it to -1 since there
> is a small, but not insignificant, chance that old code relying on Type
> declarations to be on might corrupt user data. I admit this would be
> painful in the short term, but it is better for the long term health of the
> language and parser.
>
>
>
>
> CONCLUSION
> I believe that covers all the bases needed. This will give those who want
> things to use strong typing better tools, and those who don't can be free
> to ignore them.
>
Please register a wiki account and put proposed RFC to the RFC's list.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
13.12.2017 11:44 "Tony Marston" napisał(a):
""Michal Brzuchalski"" wrote in message news:CABdc3WpomNLz+vX_m0B0wQ3u
cimiw8xw4ea_sgd-ptdgfv-...@mail.gmail.com...
> 2017-12-13 1:16 GMT+01:00 Andreas Hennings :
>
>
> Why? Because users use PSR-4 so then they're src folder looks more like:
>
?
2017-12-13 6:04 GMT+01:00 Michał Brzuchalski :
>
>
> 2017-12-13 5:38 GMT+01:00 Michał Brzuchalski :
>
>>
>>
>> 2017-12-13 5:24 GMT+01:00 Andreas Hennings :
>>
>>> On 13 December 2017 at 05:04, Michał Brzuchalski
>>> wrote:
>>> >
2017-12-13 5:38 GMT+01:00 Michał Brzuchalski :
>
>
> 2017-12-13 5:24 GMT+01:00 Andreas Hennings :
>
>> On 13 December 2017 at 05:04, Michał Brzuchalski
>> wrote:
>> >
>> > If we're going to introduce someday a namespace file, then IMO it
>&g
2017-12-13 5:24 GMT+01:00 Andreas Hennings :
> On 13 December 2017 at 05:04, Michał Brzuchalski
> wrote:
> >
> > If we're going to introduce someday a namespace file, then IMO it should
> not
> > be putted outside namespace folder.
> > For eg class Acme
y to evolve the language without BC breaks, and
> I
> > think namespace-declares are an elegant way to do this.
>
>
> So if you want a setting for explicit-send-by-ref, why not do this per
> file, as we already do for strict_types?
>
> If at some day in the future we find that the declares become too
> verbose, we could bundle multiple declares into a new setting.
> E.g. something like "declare(php=8.1);" to combine all the declares
> that would be considered default in PHP 8.1.
>
> Or introduce some other shortcut like " opening tag.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
;
>
> // fn style
> $x = "Hello"
> |> fn($x) => strtoupper($x)}
> |> fn($x) => $x . "world"
> |> fn($x) => strrev($0);
>
> // caret style
> $x = "Hello"
> |> ^($x) => strtoupper($x)}
>
ass ChainedFruitEater implements FruitEater {
> private $eaters = [];
> public function addSpecificEater(AbstractSpecificFruitEater $eater) {
> $paramClass = (new
> \ReflectionObject($eater))->getMethod('eat')->
> getParameters()[0]->getClass();
m
> - higher memory footprint of php engine?
> - more C code to maintain
> - a new doc page.
> Did I miss something?
>
> --
>
> -- Andreas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
This idea was discussed 11 months ago https://externals.io/message/94787
There is also a proper RFC
https://wiki.php.net/rfc/add_str_begin_and_end_functions
You might wanna contact with Will to get feedback from the idea.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
g some std API
is better than providing a more complex way of handling requests like
linked PSR-7 not everyone may want to use it.
There is always a way to use functional API in user-land PSR-7
implementation but not the other way.
IMHO if someone wants to use simple functional API let them use it, it may
also be used in more complex problem solutions.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
code - which is THE
ONLY ONE function prefixed this way
I just wanted to pay attention to a different naming convention which
actually exists in language, which may need to be taken as a pursuit for
all HTTP related functions.
I like http_ prefixed functions because they point HTTP related nature and
I think it may clear a little bit language API.
P.S. headers_list() may be used to retrieve all headers which are sent (or
ready to send) so you might consider introducing http_cookies_list() to
retrieve all set (and not removed) cookies in current request lifecycle.
Cheers,
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
2017-07-12 22:14 GMT+02:00 Niklas Keller :
> 2017-07-12 17:26 GMT+02:00 Michał Brzuchalski <
> michal.brzuchal...@gmail.com>:
>
>> 12.07.2017 15:35 "Mark Shust" napisał(a):
>> >
>> > Hi Aidan,
>> >
>> > I think you are correct on
1 - 100 of 189 matches
Mail list logo
