pon., 11 mar 2024 o 15:30 Larry Garfield
napisał(a):
> On Mon, Mar 11, 2024, at 8:35 AM, Michał Marcin Brzuchalski wrote:
> > Hi Larry,
> >
> > pt., 8 mar 2024 o 16:55 Larry Garfield
> napisał(a):
> >> Hi folks. Based on earlier discussions, we've made
nnot figure out anything feasible.
If this is not possible to put in understandable words then at least
mention it in FAQ and why not.
Cheers,
Michał Marcin Brzuchalski
far.
I was there in the very first link you can spot it but also believe this
goes too far.
All above already goes far beyond what you initially asked and I know that.
I just like to share what can find.
Cheers,
Michał Marcin Brzuchalski
n field list https://3v4l.org/4p6ve
O:3:"Foo":2:{s:3:"foo";a:3:{i:0;i:1;i:1;i:2;i:2;i:3;}s:3:"bar";s:3:"baz";}
Missing ; between }s was a surprise to me.
Best regards,
Michał Marcin Brzuchalski
pt., 5 sty 2024 o 13:19 Robert Landers
napisał(a):
> On Fri, Jan 5, 2024 at 11:59 AM Rowan Tommins
> wrote:
>
> > > Globals is how this works (atm)
> >
> > It's how it works for native SAPIs. It's not, as far as I know, how any
> worker system other than FrankenPHP has implemented its API.
śr., 3 sty 2024 o 15:57 Gina P. Banyard napisał(a):
> On Wednesday, 3 January 2024 at 14:38, Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> Hi Gina,
>
> śr., 3 sty 2024 o 14:41 Gina P. Banyard napisał(a):
>
> Hello internals,
>
> I
he last one.
Any thoughts about that?
Cheers,
Michał Marcin Brzuchalski
śr., 3 sty 2024 o 11:10 Nicolas Grekas
napisał(a):
>
śr., 3 sty 2024 o 08:12 Nicolas Grekas
napisał(a):
> Hi Max,
>
> Hi, I'd like to propose a new attribute, #[NotSerializable]. This
> > functionality is already available for internal classes - userspace
>
> should be (not) serialized. This is enforced and thus belongs to the
> typesystem - not to an attribute.
>
But then what should implement the NotSerializable interface?
If you want to ignore a string-typed property there would be no option to
mark it with a NotSerializable interface
Consider "baz" property in this example:
class Foo {
protected int $bar = 1;
#[NotSerializable]
protected string $baz = 2;
}
Cheers,
Michał Marcin Brzuchalski
imilar solutions used by:
* JMS/Serializer `#[JMS\Serializer\Annotation\SkipWhenEmpty]
* .NET `[JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingDefault)]`
see
https://learn.microsoft.com/en-us/dotnet/api/system.text.json.serialization.jsonignorecondition?view=net-8.0
Cheers,
Michał Marcin Brzuchalski
y SAPIs, but as far as I understood the discussion
went to figure out if there is some kind of standard approach that could be
shaped under the PHP umbrella.
Maybe this is just a temporary fascination about ASGI solution, could be.
If this is not in the scope of interest of anyone then forgive me, I won't
bother anymore.
Cheers,
--
Michał Marcin Brzuchalski
or
request response objects. These can be provided in userland which gives
more flexibility cause of different rules governing over bc break policy in
PHP core.
Name one true argument to convince me in this topic and I may change my
mind.
For the years I had the same impression but on low level the primitives are
more flexible and we all know that.
Cheers,
Michał Marcin Brzuchalski
>
e that considering the fact that ASGI provides an API for HTTP
interaction including WebSockets that could only benefit to PHP ecosystem.
In the past, I was thinking about something similar to adopting WSGI but
was not aware of ASGI.
Cheers,
Michał Marcin Brzuchalski
on _(\Closure $callback, &$var) { $var = new
self($callback); }
}
$deferred = Defer::_($closeFiles(...), $foo);
Without $foo there'd be an ArgumentCountError.
Cheers,
Michał Marcin Brzuchalski
Hi Ilija,
pt., 13 paź 2023, 13:15 użytkownik Ilija Tovilo
napisał:
> Hi everyone
>
> On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo
> wrote:
> > https://wiki.php.net/rfc/rfc1867-non-post
>
> Thank you for the feedback so far. I made a handful of changes to the RFC.
>
> * The function is renamed
m_` which better expresses the purpose then?
I'd avoid using the "post" word if we tend to provide functionality that is
common for other HTTP methods which in fact was the preliminary cause of
this discussion.
Cheers,
Michał Marcin Brzuchalski
d require just two interfaces with default methods.
Now you can easily see how bad this goes if you wanna add 3rd interface.
Cheers,
Michał Marcin Brzuchalski
pon., 3 lip 2023 o 14:26 Andreas Heigl napisał(a):
> Hey Michał
>
> On 03.07.23 13:32, Michał Marcin Brzuchalski wrote:
> > Hi Levi,
> >
> > pon., 3 lip 2023 o 02:11 Levi Morrison
> napisał(a):
> >
> >> Chatter on the [Interface Default Methods RF
pon., 3 lip 2023 o 13:50 Pierre napisał(a):
> Le 03/07/2023 à 13:32, Michał Marcin Brzuchalski a écrit :
> > I voted "yes", my personal use case waits for this feature. My use
> > case example:
> >
> > https://gist.github.com/brzuchal/89e9481bbd34a6ce3d
u'd be
including via trait
in every implementing class because as it only uses another interface
method.
This means that you don't need to know anything about the implementation
itself at all.
You're free to use other interface methods and don't need any properties or
implementation details.
Cheers,
Michał Marcin Brzuchalski
mentation of the interface but
when I decorate to apply some:
* caching
* logging
* failover
then the trait has to be attached to every class besides that it has to
exist which is an additional symbol here.
Cheers,
Michał Marcin Brzuchalski
se one of
> the request-objects that are already out in the wild. I don't think
> there's a need to invent the wheel again.
>
> The advantage might be that no matter how many calls to `request()` you
> will always get the same result. The Request as it came in.
>
That sounds like a use for a const?!
Just my .50€
Cheers,
Michał Marcin Brzuchalski
Hi Máté,
pon., 29 maj 2023 o 11:18 Máté Kocsis napisał(a):
> Hi Everyone,
>
> In the meanwhile, I changed my proposal to use [] instead of {} after the
> "with" clause due to its better receptance.
> Additionally, I removed support for the shorthand "property assignment"
> syntax (clone $this
of $field, however, and thus a
backing value will be created, and write operations will simply write to
the property as normal.
This looks like new magic to me, whether we allow setting and baking the
value explicitly or not. I consider this behavior confusing.
Overall I vote yes.
Cheers,
Michał Marcin Brzuchalski
thod is confusing as the method magically appears on a
closure without explicit binding to it! What if an interface has more than
one method? What if I wanna choose which one?
For me personally this goes into wrong direction.
Cheers,
Michał Marcin Brzuchalski
>
oInts $c): int
> {
> return $c(1, 2);
> }
>
> $result = takeTwo(fn(int $x, int $y): int => $x + $y);
>
I'd love to see this happening.
[1]
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/delegates/
Cheers,
Michał Marcin Brzuchalski
unction call allowing easily to
distinguish
between two different things.
Cheers,
Michał Marcin Brzuchalski
if it could
be a separate feature
allowing for passing named arguments to functions/constructors in the same
fashion?
$something = new Something(
foo() => bar(),
quux() => baz(),
);
Cheers,
Michał Marcin Brzuchalski
rious if possible to implement the feature without using `with`
keyword
it visually could look pretty close to something like an object initializer
in the future:
return clone $this {c: 1};
return new Bar {c: 1};
Cheers,
Michał Marcin Brzuchalski
from "use" to property if needed?
Like desugar to
$c = class ($a, $b) use ($c) {
private $c = $c; // optional, not required, no conflicts
public function __construct(private int $a, private int $b) use ($c) {
$this->c = $c % 2 ? 3 : 5;
}
public function something() use ($c) {
return $c;
}
}
Or there is something so wrong with this thinking I cannot see yet.
Cheers,
Michał Marcin Brzuchalski
nor issues with SPL autoload. However, I think it'd be
worth
mentioning them in RFC so the reader can get a complete picture of what
the RFC tries to address besides adding new features like function autoload.
Cheers,
Michał Marcin Brzuchalski
d argue with that because I think the spread operator should be
consistent with preserve keys strategy used in other places.
Cheers,
Michał Marcin Brzuchalski
>
lean.
> https://3v4l.org/RcKRD
If a parameter of array_push is a dictionary it fails with:
Fatal error: Uncaught ArgumentCountError: array_push() does not accept
unknown named parameters
See https://3v4l.org/BHPSt
Best regards,
Michał Marcin Brzuchalski
unsubscribe, visit: https://www.php.net/unsub.php
>
>
Personally, I'd like the unserialize to throw an exception if trailing
bytes are detected.
If not by default then with the use of the option passed to unserialize
function.
Cheers,
Michał Marcin Brzuchalski
ality is like a pipe operator
* apply() - which you can call without the option to bind/rebind and just
pass arguments for execution
The pipe operator can be introduced later, but we could already have the
functionality on Closure.
The above example might look readable as well:
$size = amap(...)->partial(chr(...))
->andThen(implode(...)->partial(','))
->andThen(length(...))
->apply($arr);
Cheers,
Michał Marcin Brzuchalski
Hi Deleu,
śr., 1 mar 2023 o 16:54 Deleu napisał(a):
>
>
> On Wed, Mar 1, 2023 at 9:36 AM Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>>
>> Do we really need this in core? What makes it less usable as an extension?
>>
t; automatic generation from the class that I mentioned before) so it will be
> better to have it in the class.
>
> Regards
>
> Jakub
>
Do we really need this in core? What makes it less usable as an extension?
Cheers,
Michał Marcin Brzuchalski
>
e return value, and therefore the `return`
> instruction might be reasonably omitted.
>
I like the idea of `$this` as a return type but also strongly believe that
the use of `return $this;` should be forbidden,
eventually for control flow use of `return;` might be justified.
Cheers,
Michał Marcin Brzuchalski
backward incompatible changes section few sections are copied
twice.
In overall I like the RFC as it gives wide range of exceptions providing
detailed information. Thanks.
Cheers,
Michał Marcin Brzuchalski
>
the cleanup with planned standard library
function removal would be complete.
Cheers,
Michał Marcin Brzuchalski
$response
>
This is somehow confusing, why is the $response storing object ref is ok
while inclining the new object creation is not?
This requires more attention while reading and debugging.
Cheers,
Michał Marcin Brzuchalski
lizing invalid objects? This could help you.
Also that sounds more logical to me as I don't see any reasons to
initialize invalid objects if it's a matter of simple validation instead.
P.S. I don't see it feasible to have objects that evaluate false in
logical expressions.
Cheers,
Michał Marcin Brzuchalski
() => compact($name))();
I agree with the idea of deprecating compact() & extract() and in
long-term variable of variables as well.
Cheers,
Michał Marcin Brzuchalski
probably not something
impossible
as it required around 1h of work to port it see working implementation
here https://gist.github.com/brzuchal/37e888d9b13937891c3e05fead5042bc
Cheers,
Michał Marcin Brzuchalski
Hi Juan,
pt., 26 sie 2022 o 11:26 juan carlos morales
napisał(a):
> El vie, 26 ago 2022 a las 11:00, Michał Marcin Brzuchalski
> () escribió:
> >
> > A `json_decode()` is a substitute that IMO solves 99% of use cases.
> > If I'd follow your logic and accept every small
Hi Dusk,
pt., 26 sie 2022 o 08:17 Dusk napisał(a):
> On Aug 25, 2022, at 21:47, Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
> > The same goes here and I'm not convinced we should introduce next small
> function that can be simply implemented in user l
small functions that could have not exists and be replaced with
normal PHP counterparts IMHO we'll end with frustration from developers as
I believe DX slowly falls down here.
Cheers,
Michał Marcin Brzuchalski
>
re storing each Collection class entry patched by a
given extension for each class name - but these things are not really
runtime at all - meaning we may end up with a blocker because namespaces
are not a real thing in PHP.
Cheers,
Michał Marcin Brzuchalski
fiers to the right
but enclosed with parentheses, this way a future stays open for
improvements and introduction of accessors.
// instead of
class Foo {
public private(set) static int|string $id;
}
// let's do this
class Bar {
static int|string $id {
public;
private set;
};
}
A future improvement may add an accessor body on the right side of "set".
Cheers :D,
Michał Marcin Brzuchalski
r word).
Cheers,
Michał Marcin Brzuchalski
code() generates an in memory an
> object/array (depending on parameters) while parsing the string; this leads
> to a memory usage that is not needed (because we use memory for creating
> the object/array) and also can cause an error for reaching the memory-limit
> of the php process.
>
Personally I'd vote NO.
Cheers,
Michał Marcin Brzuchalski
>
array keys feature first instead (which
the RFC reminds
in its introductory section as not possible yet) before we start improving
places around enums.
Best regards,
Michał Marcin Brzuchalski
in
> > PHP.
> >
> > [1] http://joeduffyblog.com/2016/02/07/the-error-model/
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit:
> > https://www.php.net/unsub.php
>
> There's also a decent article here
> https://www.artima.com/articles/the-trouble-with-checked-exceptions where
> Anders Hejlsberg discusses the problems he sees with checked exceptions.
>
Thanks for the link it was really interesting to see issues with checked
exceptions based on someone's experiences.
Cheers,
Michał Marcin Brzuchalski
y afraid that such a mix of responsibilities can lead to bad habits
when it gets to the separation of concerns by developers who get used to it
and won' see the problem as I do.
Cheers,
Michał Marcin Brzuchalski
is->firstName;
}
I'm asking if I understand the scopes of this and previous RFCs correctly
and if they don't block in future "short-methods"?
Cheers,
Michał Marcin Brzuchalski
Maybe it is just because of using Doctrine DBAL often, but IMO here a
better input might have its contributors.
Best regards,
Michał Marcin Brzuchalski
tribute use case came up recently in Symfony. I'm in favor
> and the RFC looks good to me.
>
Personally, I'd start the discussion on
https://wiki.php.net/rfc/object_keys_in_arrays instead as this might solve
the need for
fetching property in constant expressions.
Cheers,
Michał Marcin Brzuchalski
I don't have much to say on that besides that I feel it's a great idea
and if that can be built with parametrized type streams (not limited to
strings only)
then I'd be even more thrilled with such functionality.
Thanks for this idea and I hope it get materialized soon.
Cheers,
Michał Marcin
is worth the added language
> complexity + removal of power.
>
I'd say this is a very weak argument, we do the same with the final on
class, method, property level already.
But well, it's your vote.
Cheers,
Michał Marcin Brzuchalski
ok at the Iraquis who were attacked by the USA, the Uyghurs in China,
> the poulation in Noth Korea or the war in Yemen. Thousands of people are
> dying there every year and nobody is raising his voice.
>
In 7d almost 10 thousand died in Ukraine (including both sides). Not in a
year!
If you don't see this then I have no words.
--
Michał Marcin Brzuchalski
nd peace.
>
> I think that's something everyone could agree with.
>
> Let me know what you all think.
>
I wanted to express it by an example but cannot find better words which
took me almost 15m, so I'll try to use simple words instead.
No. IMHO that's not enough.
--
Michał Marcin Brzuchalski
against injustice.
>
Thanks!
I do not agree to do nothing!
If this could reach anyone through Putin's propaganda, I'd say it was worth
it!
I'm pretty sure it can be explained that the support was spread because of
the clearly blatant war crimes against the Ukrainian people and totally
unjustified aggression.
--
Michał Marcin Brzuchalski
> >
> > Please do not start that.
> >
> > You and anybody else can show their political position on twitter,
> > facebook or elsewhere. We do not need to do that on php.net.
> >
>
> Please GTFO: we don't need more of Putin's propaganda over here, as they're
> busy enough with butchering civilians over there.
>
+1 full support, you got my keoboard.
Cheers,
Michał Marcin Brzuchalski
because I don't like populating standard library with small
functions of rare use
which are easily replaceable by a simple set of statements and/or
expressions.
Best regards,
Michał Marcin Brzuchalski
t implements MyInterface;
> $object !implements MyInterface;
> $object extends MyClass;
> $object !extends MyClass;
> ```
>
Why not "not" instead? The "!" in front of "i" in "!implements" is almost
not visible which IMO could get easily ignored
y-value, built-in object initializer and class composition over
inheritance like Go structs.
But regardless of what I'd love to see this feature, I see no justified use
case.
Therefore I ask if there are any real use cases of it? and if there are
other languages with similar functionality?
Cheers,
Michał Marcin Brzuchalski
Hi Máté,
pon., 22 lis 2021 o 17:14 Máté Kocsis napisał(a):
> Hi Internals,
>
> I'd like to propose adding support for readonly classes:
> https://wiki.php.net/rfc/readonly_classes
Did you forget to update the status?
Cheers,
Michał
pon., 15 lis 2021 o 13:03 Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> napisał(a):
> Hi Rowan,
>
> pon., 15 lis 2021 o 12:34 Rowan Tommins
> napisał(a):
>
>> Hi all,
>>
>> Concerns have been raised a few times recently about adding
like this:
$fp = @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');
introduce statement level attributes which can be backward compatible when
in one line
$fp =
#[SupressErrors(E_WARNING)]
fopen($undefinedVariable, 'r');
What do you think?
Cheers,
Michał Marcin Brzuchalski
rce and check the return $this why
would we still need/require return statement to be obligatory?
Does that make sense to assume at the end of function flow the return
$this; statement to be present by default if the return type is not an
union etc.?
Cheers,
--
Michał Marcin Brzuchalski
> What do you think ?
>
I think a Markdown document including PHP code snippet with above examples
could cause issues while parsing.
I can imagine parsers don't expect end-of-snippet tag "```" being not an
end tag actually.
Cheers,
Michał Marcin Brzuchalski
to standard library
which are from a language perspective irrelevant
and that all could be developed in userland with no harm.
Cheers,
--
Michał Marcin Brzuchalski
czw., 27 maj 2021 o 13:29 Pierre napisał(a):
> Le 26/05/2021 à 21:24, Michał Marcin Brzuchalski a écrit :
> > I don't think nowadays anyone does that without a kind of deserializer
> > which
> > reads the metadata of desired DTO and like Symfony's Serializer or JM
public ?bool $unknown = null,
...$additional,
) {}
}
Then is passing built-in language sort of validation.
If you wanna allow passing more values than expected, add not used variadic
argument at the end.
Variadic argument solves the issue with missing named arguments which might
appear in the future.
These examples show a very simple solution to container classes such as DTO.
All of them avoid dealing with an uninitialized state.
IMHO there really is no need to deal with uninitialized properties in DTO!
Cheers,
Michał Marcin Brzuchalski
t be) to have such a need.
Cheers,
Michał Marcin Brzuchalski
pon., 17 maj 2021, 16:31 użytkownik Larry Garfield
napisał:
> On Mon, May 17, 2021, at 9:16 AM, Michał Marcin Brzuchalski wrote:
> > pon., 17 maj 2021, 16:02 użytkownik tyson andre <
> tysonandre...@hotmail.com>
> > napisał:
> >
> > > Hi internals,
> &g
to provide more real life example?
The example in RFC could easily encapsulate current Environment reading in
for eg. EnvironmentConfiguration class with static property and method and
TBH possibly that would be my preference to solve this.
Cheers,
Michał Marcin Brzuchalski
>
language change, even if not a particularly important one...
>
Glad to see this topic. That's a YES
Cheers,
Michał Marcin Brzuchalski
czw., 6 maj 2021, 17:23 użytkownik Sara Golemon napisał:
> On Thu, May 6, 2021 at 10:10 AM Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> czw., 6 maj 2021, 16:01 użytkownik Christoph M. Becker > >
>> napisał:
>>
>>
ere potentially someone who could help with reviews?
Cheers,
Michał Marcin Brzuchalski
>
ause there is no effective way to
restrict input string to be a valid class or interface name and second that
it'd require passing strings which means in most cases passing class or
interface name with magic ::class constant read.
Cheers,
Michał Marcin Brzuchalski
described in the RFC.
In general I love the proposal was especially thinking of it for static
variables.
Cheers,
Michał Marcin Brzuchalski
>
e) have more
benefit over class name string operations as they're easy for any renaming
which most of the IDE's these days can handle.
IMO introducing namespace magic constant has relatively narrow use and I'd
probably vote NO on this.
Cheers,
Michał Marcin Brzuchalski
n type, but IMHO
it looks better and reads easier
when moved before enum name:
enum:string Suit {
case Hearts = 'H';
}
Leaving the space between enum name and bracket for further extensions in
future.
What do you think?
Cheers,
Michał Marcin Brzuchalski
suit = (Suit) $record['suit'];
Instead of:
$suit = Suit::from($record['suit']);
Cheers,
Michał Marcin Brzuchalski
talking about reducing the return type at all for void methods.
Cheers,
Michał Marcin Brzuchalski
function getBar(): int => $bar;
public function setBar(int $value) > $bar = $value;
}
Would it be possible?
If not I think we should reanimate property accessors.
Just dropping my 50 cents.
Best regards,
Michał Marcin Brzuchalski
wt., 20 paź 2020 o 20:20 Larry Garfield napisał(a
Hi,
czw., 1 paź 2020 o 11:36 肖 鑫鑫 napisał(a):
> I commit a new request path, the request is about execution opcode file
> without php source code file
> this RFC provides similar to class file of java and pyo file of python.
> patch is: https://github.com/php/php-src/pull/6146
I had exact the
it differs when
considering more than 2 attributes in groupped syntax.
What I mean is that @@ requires always 2*N amount of chars which for 3
attributes is 6 while for syntaxes like #[] it is only 3 for N=1 and only
3+N-1 for N>1 which for 3 attributes is only 5 and adds always only 1
additional required chars for next additional attribute due to fact that
grouped syntax requires only one comma "," between attributes.
Cheers,
Michał Marcin Brzuchalski
>
Hi Andreas,
sob., 15 sie 2020, 12:24 użytkownik Andreas Leathley
napisał:
> On 15.08.20 11:54, Michał Marcin Brzuchalski wrote:
> > I don't think there's anything significant changed in the RFC. I really
> > doubt the vote result will change significantly.
> >
> > Cu
, and therefore cannot
> be considered valid.
>
> If vote fatigue is really the most important consideration here,
> would this RFC have been brought to vote in the first place?
>
I don't think there's anything significant changed in the RFC. I really
doubt the vote result will change significantly.
Currently you're the only one who wants to wipe the vote and there is no
much voices willing to follow your proposal.
Personally I think extending the vote by additional week is fair enough.
Cheers,
Michał Marcin Brzuchalski
>
Hi Theodore,
czw., 13 sie 2020 o 15:17 Theodore Brown
napisał(a):
> On Thu, Aug 13, 2020 at 3:13 AM Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> > Hi Theodore,
> >
> > śr., 12 sie 2020 o 18:36 Theodore Brown
> napisał(a):
> &g
it can be seen
that your proposed syntax is no longer the leading one.
I understand it fully cause I'd be upset as well.
>From my own experience, I know that as a RFC author there has always be
a place to just let it go
cause you won't always get to convince 50+ voters to your PoV.
Cheers,
Michał Marcin Brzuchalski
[1]: https://externals.io/message/111218#111254
[2]: https://wiki.php.net/rfc#declined
[3]: https://externals.io/message/110640#110819
[4]: https://externals.io/message/01#01
[5]: https://externals.io/message/01#32
and maybe it's worth to put it
as a PECL extension. Please correct me if I'm wrong.
Thanks for participating.
Cheers,
Michał Marcin Brzuchalski
wt., 21 lip 2020 o 13:52 Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> napisał(a):
> Hi Internals,
>
> I've opened the voting fo
> last vote, and this proposal is identical to the one declined in the
> previous RFC.
>
Which declined/rejected RFC you're referring to?
I can't find it on the list[1] but would for sure like to read it again.
[1] https://wiki.php.net/rfc#declined
Cheers,
Michał Marcin Brzuchalski
ools.
TL;DR
Now please bear in mind that I'm just saying that people from Larevil
community already
can use the same syntax with double "@@name()" in ".php" files but outside
of PHP code context.
[1] https://laravel.com/docs/7.x/blade#blade-and-javascript-frameworks
Cheers,
Michał Marcin Brzuchalski
It's hard to rely fully on your statement considering such a mistake.
Cheers,
Michał Marcin Brzuchalski
ironment settings, docker -e options, or by editing a deployment on k8s
by hand to apply different settings for investigation purposes.
I'd like to hear other opinions about it.
Cheers,
Michał Marcin Brzuchalski
to adjust ini directive values by simple
environment variables.
I believe there should be no two ini directives which could be ambiguous
like for eg. "memory_limit" and "memory.limit" and cause issues on ini
directives lookup by env variable name like PHP_MEMORY_LIMIT.
Cheers,
Michał Marcin Brzuchalski
>
Hi Derick,
śr., 22 lip 2020 o 14:00 Derick Rethans napisał(a):
> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
> - There are lots of grumbles, both on here, room 11, as well as in the
> wider community
1 - 100 of 116 matches
Mail list logo
