>
> $person = new Person("Name", 43) {
>
firstName: "John",
>
age: 42
>
};
Hi!
You could achieve similar functionality with a simple user-land method
"assign". If you put such a method on a trait, you can use it everywhere.
See the example:
$propVal) {
$this->$prop
Hello, everyone.
I'm sorry for not being active for a time on the internals, including about
this RFC of mine.
I just had a huge house-related problem and recently also health problems
with my family.
So, I'll have to stay away for some time. But I'll go ahead with the talks
about this RFC as soon
Hi all.
Answering to Larry:
> More complex initialization of things like lookup tables or "dynamic
constants" (like if you wanted to record "now" to use for later
comparisons).
Those are my use cases, to be honest.
> For that reason, therefore, I don't like the current approach, especially
for th
Hi, Michał.
> Have you considered naming it for example shortly `function __static()` ?
I have considered some names, actually. I just chose this one for the
implementation because
I tried to design it to be as close as possible to the C# implementation
and they call it "static constructor".
But
Hello everybody.
I found myself wanting this feature (that I first encountered when
programming in C#) for removing a workaround from a codebase I work from
time to time.
I searched internals and found a discussion from almost a decade ago. That
discussion did not end well, mostly because of insul
> I have granted you RFC karma. Good luck!
Thank you, Ilija
> Note that the RFC process suggests first introducing the concept on
> the list first, before writing an RFC. You might save yourself some
> time if the idea turns out not to be desired.
Yes, I know. I started creating the RFC implement
Hi all!
I've been reading the internals mailing list for some time and giving my 2
cents here and there.
Now I have created a new wiki account (erickcomp) and I'd like to request
RFC karma for a new RFC I worked on during my recent studies of the php-src.
Thank you,
Erick Lima
> Please, don't make PHP as unreadable as Perl. IMO It's two extra
characters at worst and would be solved much more elegantly by removing the
new keyword entirely.
The new keyword is meaningful and everyone knows what's being done just by
looking at it. Removing it would make the language less r
Hi all.
> Em sex., 7 de jun. de 2024 às 17:53, Pierre
escreveu:
> I do agree with you that when you use value objects, you need it a lot,
> but I'd much prefer having a JS like value objects initializer syntax,
> such as `Point {x: 1, y: 2}` syntax than creating another way to call
> the construc
> So we feel the best way forward is to make the following changes:
>
> * private(set) implicitly means "final". (You can declare it explicitly
if you want, but it isn't necessary.)
> * Make readonly incompatible with aviz again.
I'd make readonly incompatible with aviz. Readonly props have its
"
Hi.
> I like the idea. But I don't know
Please ignore this.
Some copy-past leftovers.
Sorry!
> To resolve these issues, change the naming to something appropriate and
use Enums instead of int constants.
Hi!
I like the idea. But I don't know
>From the RFC text:
> To summarize, existing features will be changed to a union type of int|
\RoundingMode, and unreleased features will only accept
> If we're talking syntax and introducing new keywords anyway, why not go
with a new language construct like `is_initialized($obj->property)` ?
It was one of my suggestions at the beginning of the thread. Also, I said
that I'd love the "$objectVar->property is uninitialized" (answering to
Larry)
b
;property is initialized) {
...
}
--
Erick de Azevedo Lima
Em seg., 20 de mai. de 2024 às 14:28, Larry Garfield
escreveu:
> On Sat, May 18, 2024, at 5:41 PM, Rowan Tommins [IMSoP] wrote:
> > On 18 May 2024 17:13:49 BST, Larry Garfield
> wrote:
> >>However, that breaks
> I am already using a solution like the one
> proposed by Robert: it works but it leaves some doubts since each project
> can have a different name for NotSet while it seems a general concept of
the language
Hi everyone.
I just thought of some ways to standardize this:
1 - Create an RFC to crea
> Reminder to not run into a sunk cost fallacy.
My main point was not the cost/work itself, but the fact that big concerns
should be raised ASAP, and not on the 11th hour, as Robert said.
Whether we like it or not, the voting right beholders' concerns should be
taken into account with "special att
> As someone who has spent a number of years writing C#, the RFC look>
quite sane.
Same here.
> Removing it because "it complicates things" isn't really a good reason,
IMHO.
I think the same. FFI, for instance, is powerful but one can make a mess
with it.
> Then watching the feedback here, at the
> Instead, we are planning to re-propose asymmetric visibility once
> property hooks are merged, as it may become more apparent why it is
> useful.
I was talking today to a co-worker about this internals e-mail discussion
and he thought asymmetric visibility was inherent to property-hooks.
He even
> It sounds like most people are just really, really pissed off by an
implicit variable
I think that it could be good to follow the PHP way to mark the "magic"
stuff, which is putting leading underscores on the magic stuff. It's not
pretty, but it's good because our eyes can detect the magic stuff
> If I'm using gmail and not getting emails, how many other people are
> also not getting emails on this list?
Same here.
It's really nice!
>>> We are willing to do so if the consensus is that it would be
beneficial, but want to ask before putting in the effort.
I really think that it's not necessary, as the it still hooks into the
default behavior of the properties.
Even though I don't have voting privileges, I'm r
3 às 18:52, Erick de Azevedo Lima <
ericklima.c...@gmail.com> escreveu:
> Hi Jordan.
>
> What's the name of the library you're talking about? Maybe the cons of a
> core implementation can be highlighted if we can see the limitations of a
> user-land approach.
>
> B
Hi Jordan.
What's the name of the library you're talking about? Maybe the cons of a
core implementation can be highlighted if we can see the limitations of a
user-land approach.
Best,
Erick
Em ter., 12 de dez. de 2023 às 18:35, Jordan LeDoux
escreveu:
> On Tue, Dec 12, 2023 at 1:26 PM Larry Ga
I'm in favor for this. I think that, since you already have a built-in file
API, adding useful functions is always good. I use *\str_starts_with* and
*\str_ends_with* a lot in my code. In Laravel, which is the most used
Framework these days, you have the \Illuminate\Supports\Str::startsWith and
\Il
File-based are the worst.
Let the types be attached to namespaces. As we have autoloaders, everyone
is free to load them however they want (PSR-4, file, custom autoloader,
whatever).
Best regards,
Erick
Em seg., 30 de out. de 2023 às 08:34, G. P. B.
escreveu:
> On Sun, 29 Oct 2023 at 20:36, Ro
I'll use it a lot if they'll be namespaced. It avoids name-collision using
the existing ecosystem and we already use lots of "uses" in our codes.
When Enums came to the party, they came namespaced as traits, classes and
interfaces. The last 2 represent types, concrete and abstract.
User defined typ
Thanks for the feedback.
I hope everything works well for Ilija. Thank you also for the good work
you have done.
--
Erick de Azevedo Lima
Em dom., 2 de jul. de 2023 às 09:52, Larry Garfield
escreveu:
> On Mon, May 8, 2023, at 4:38 PM, Larry Garfield wrote:
> > Ilija Tovilo and I woul
Hey everyone.
Any news on this? I'm really excited about this one. =)
--
Erick de Azevedo Lima
Em ter., 30 de mai. de 2023 às 14:15, Larry Garfield
escreveu:
>
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
> On Mon, May 29, 2023, at 8:28 PM, Claude Pache w
Hello you all.
As closures are objects, I'd be ok with $this->__invoke(), but it's not
possible because closures can be bound to other contexts.
>From the proposed solutions, the one that makes more sense to me is the
__CLOSURE__, because not only it does not need
the boilerplate that can be confu
As others have said: the interface/contract makes available public stuff
that is what the implementers will make available. So it should not matter
if those are methods or properties.
In the case of a public property, the difference from the method-only
approach is that it's already implicit that t
I can't wait!
Especially because I'm heading a modernization of the systems in my
organization and my plan is to use the cutting edge PHP version for it.
Currently our internal "framework" uses PHP 7.4, but with a PHP 5.6 coding
style.
Again: I can't wait!
I can't do much but thank everyone who s
It looks great!
Thank you so, so much. I've been wanting this for a long time. I have used
properties in C# and it's very useful. I'm reading this RFC since it was in
draft. =)
One thing that I did not understand was this piece of code:
class C {
public array $_names;
public string $names
32 matches
Mail list logo
