equired to work with interfaces.
I believe these adjustments could make the Interface Default Methods more
palatable to the community, ensuring that the feature enhances PHP without
introducing unnecessary risks.
Just thinking out loud here - looking forward to hearing some thoughts.
Cheers,
Mich
ike Symfony and others that one lays in `public/` folder as an
entry point, often this is the only file in this directory.
If I understand your idea correctly you'd like a couple of I/O operations
on the filesystem to find the `.php-packages` directory in CWD else if not
in the parent directory and so on rather than directly pointing where it
is, right?
Cheers,
Michał Marcin Brzuchalski
pon., 1 lip 2024 o 03:01 Larry Garfield napisał(a):
> On Sun, Jun 30, 2024, at 11:13 AM, Michał Marcin Brzuchalski wrote:
> > Hi Richard,
> >
> > czw., 27 cze 2024, 22:33 użytkownik Richard Miles
> > napisał:
> >>
> >> > I worked with Joe Wat
erspective. While typed array seems much more clear and
compatible in all places where typed array is needed without declaring
separate type for each usage.
If I were to choose between typed-array and collection like Derick showed a
little bit I'd choose typed arrays definitely as a first feature to be
merged into PHP.
Cheers,
Michał Marcin Brzuchalski
>
structing
objects.
Have you considered naming it for example shortly `function __static()` ?
It is somehow similar to https://wiki.php.net/rfc/static_constructor#java
in static-block.
Cheers,
Michał Marcin Brzuchalski
s.
I see potential in this kind of declaring these directives for future
extensions.
This is something I'd love to consider instead of just renaming things we
already have.
Cheers,
Michał Marcin Brzuchalski
if it
doesn't limit functionality,
but for me, it is way more clean and easier to understand.
Cheers,
Michał Marcin Brzuchalski
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
me and TBH cannot 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
' are necessary). Or maybe that goes too 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
as object property it is not
followed by ; in 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. Every
ś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 wou
onse headers instead of just the 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
> sho
g itself how it
> 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
://3v4l.org/6b1Y6
Similar 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
code.
I know there is a Runtime library, that tries to integrate
Symfony/Laaravel to many 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
e. Looking at WSGI or ASGI there is no need for
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
>
ility.
I believe 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
tic function _(\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 to
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
and
FooWithBar.
With this RFC that would 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
which you'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
re is one implementation 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
al namespace and then we can use 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 wi
ing example does make use 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
with a method 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
>
n takeTwo(TwoInts $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
lar function call allowing easily to
distinguish
between two different things.
Cheers,
Michał Marcin Brzuchalski
ring 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
lues 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
;
I'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
>
ple/clean.
> 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
o 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
nction.html
* andThen() - which functionality 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
ward 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
>
oins 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
name = 'x';
(fn () => compact($name))();
I agree with the idea of deprecating compact() & extract() and in
long-term variable of variables as well.
Cheers,
Michał Marcin Brzuchalski
by json.org is 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
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 u
e keep the tendency to pollute already bloated standard library with an
army of 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
>
sal would require 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
let's move
all the visibility modifiers 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
27;t find
better 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
>
ms as 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
eady for that kind of fundamental rethink of how error handling works 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
uch.
I'm only 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
> $this->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
s for a smoother
transition.
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
m-in-attribute 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
27;t think this 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
too.
>
> Look 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
uel. It's standing up 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
gt; sure.
> >
> > 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
gt; $object 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 easi
get
pass-by-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
w syntax backward incompatible 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
e is to force 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
ntax is more similar to Markdown syntax.
>
> 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
`
I get an impression that we constantly add things into 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
ing $name,
public int $width,
public int $height,
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
#x27;s not common (or at least should not 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
ou be able 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
>
; is a 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ł:
>>
>>
Is there potentially someone who could help with reviews?
Cheers,
Michał Marcin Brzuchalski
>
two reasons: first because 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
to be described in the RFC.
In general I love the proposal was especially thinking of it for static
variables.
Cheers,
Michał Marcin Brzuchalski
>
her they're aliased or used in use clause) 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
re
enum name?
I think it was put here to look similar to function return 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
considered instead?
For eg.
$suit = (Suit) $record['suit'];
Instead of:
$suit = Suit::from($record['suit']);
Cheers,
Michał Marcin Brzuchalski
te the void
if talking about reducing the return type at all for void methods.
Cheers,
Michał Marcin Brzuchalski
public 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ł
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
what I've noticed is that 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.
> >
&g
s not reflect the contents of the RFC, 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
hard to find an argument
against the re-vote.
>From the results which are available so far, 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
1 - 100 of 123 matches
Mail list logo