Hi Jakob,
On Tue, 31 Mar 2020 at 02:58, Jakob Givoni wrote:
> - Will COPA pollute the symbol/syntax space? Very little
> - Does COPA have any implications for future language evolution? None
> that have been shown so far
>
COPA is by its nature a brand new syntax, and that does have implication
Hi,
> In this case, the problem with COPA as proposed is that it only works for
> public properties that are assigned literally. That is, in my experience,
> a very rare case.
>
> You see, here's the funny thing: It's rare because it's a hassle!
> *MY* experience (I do have some 20 years' worth o
Hi Larry!
I have a lot of respect for the vision you're working on. Great
advances sometimes come out of great visions.
But let's not forget that so far it's only a vision and not all
visions come to fruition. We don't know - at the moment it's anybody's
guess.
At this point I hardly expect you t
Hi Levi,
On Sun, Mar 29, 2020 at 8:06 PM Levi Morrison
wrHote:
>
> The current RFC text is not consistent with using `=` or `=>` for the
> assignments. The assignment `=` is vastly more common, though, and I
> don't understand why if we are using an array syntax we aren't using
> `=>`.
Not sure
Hi Jakob,
On Sun, 29 Mar 2020 at 21:57, Jakob Givoni wrote:
>
> I understand and fully agree that COPA is narrow, but I don't really
> understand why that's a problem - I proposed it exactly because I felt that
> its simplicity is its force.
> Low hanging fruit is usually something I would encou
On Mon, Mar 30, 2020 at 3:06 AM Levi Morrison via internals <
internals@lists.php.net> wrote:
> The current RFC text is not consistent with using `=` or `=>` for the
> assignments. The assignment `=` is vastly more common, though, and I
> don't understand why if we are using an array syntax we are
The current RFC text is not consistent with using `=` or `=>` for the
assignments. The assignment `=` is vastly more common, though, and I
don't understand why if we are using an array syntax we aren't using
`=>`.
I intend to vote no. I agree that we need to do something in this
space, but this is
On Sun, Mar 29, 2020, at 3:57 PM, Jakob Givoni wrote:
> Hi Rowan,
>
> On Sun, Mar 29, 2020 at 10:00 AM Rowan Tommins
> wrote:
>
> >
> > myObj.with {
> > foo = 10
> > bar = foo + 20
> > }
> >
>
> I really like the suggested "with" syntax, - in fact I had
> contemplated something like t
Hi Andrea,
On Sun, Mar 29, 2020 at 10:31 AM Andrea Faulds wrote:
>
>
> (function ($obj) {
> $foo = "foo";
> $bar = "bar";
> $baz = "baz";
>
> $vars = get_defined_vars();
> foreach ($vars as $key => $value) {
> $obj->$key = $value;
>
Hi Rowan,
On Sun, Mar 29, 2020 at 10:00 AM Rowan Tommins
wrote:
>
> myObj.with {
> foo = 10
> bar = foo + 20
> }
>
I really like the suggested "with" syntax, - in fact I had
contemplated something like that along the way.
The slight "problem", I think, is that, as you mention, adding
Hi Rowan,
Rowan Tommins wrote:
Hi Jakob,
It occurred to me thinking about alternative syntaxes that COPA could be
seen as a limited form of the "with" statement found in some languages,
e.g. JS [1], VisualBasic [2], Delphi [3], Groovy [4] (note that with
blocks in Python are something diffe
On 28/03/2020 21:37, Jakob Givoni wrote:
I really believe that COPA can help thousands of PHP developers
without introducing any new complexities to the language and my hope
is that perfect won't be the enemy of good this time around :-)
Any last words unsaid before the final lap commences?
H
On Mon, Mar 16, 2020 at 6:48 AM Jakob Givoni wrote:
>
> Hello Internals,
>
> I'm opening up my new RFC for discussion:
>
> https://wiki.php.net/rfc/compact-object-property-assignment
> - A pragmatic approach to object literals
>
> Let me know what you think!
>
> Best,
> Jakob
Hi again,
Since the
I just realized that syntax C and D as proposed - without anything to
signify end of COPA - become really awkward when writing nested COPA:
$foo->
a = 1,
b = 2,
c = (new Foo)->
a = 3,
b = 4,.
,
;
How do we indicate that the nested block ends and jump back to the ou
Hi Andrea, thanks for your feedback.
Let's talk about syntax then :-)
The currently suggested syntax is
-> [
= ,
...
]
The can be an existing object:
$foo->[a = 1];
Or a new, yet anonymous, object:
(new Foo)->[a = 1];
1. The (normal) brackets
===
The reason I thin
On 21.03.2020 at 19:31, Andrea Faulds wrote:
> However, we don't have to be so imaginitive and adapt a similar feature,
> because C# already has the exact feature you are proposing, and calls it
> “object initialisers”:
>
> Foo foo = new Foo {
> bar = 1,
> baz = 2,
> };
>
>
Hi,
Jakob Givoni wrote:
Hello Internals,
I'm opening up my new RFC for discussion:
https://wiki.php.net/rfc/compact-object-property-assignment
- A pragmatic approach to object literals
Let me know what you think!
Best,
Jakob
I really don't like this `(new Foo)->[]` syntax for a few reason
On Wed, Mar 18, 2020 at 12:27 AM Michał Brzuchalski
wrote:
> Using Object Initializer enforce that if a class is instantiated with the
> Object Initializer,
> at the end of the instantiation and properties initialization, all visible
> properties
> (depends on initialization scope) are initiali
ś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
> > could reduce the boi
On Mon, Mar 16, 2020 at 9:07 PM Jakob Givoni wrote:
> Thank you for your feedback so far!
I've rewritten parts of the RFC substantially
(https://wiki.php.net/rfc/compact-object-property-assignment)
so take another look if you too have ever wanted to
create, populate and send an object inside a fun
On Tue, Mar 17, 2020 at 9:31 AM Rowan Tommins wrote:
> Hm, I see, that does reduce the boilerplate somewhat, although it's still
> split across two classes, and probably therefore two files, which is not
> great.
As an alternative to passive associative arrays, it's a small price to pay for
splitt
On Tue, Mar 17, 2020 at 4:33 PM Matthew Brown wrote:
> I don't think it's conflicting _if you insist on brackets_ after the new
> expression. PHP Parser grammar for "new" expressions is
>
> T_NEW class_name_reference ctor_arguments
>
> If you allowed the shorter syntax, ctor_arguments would allow
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
> could reduce the boilerplate on initializing object and setting their
> properties in on
I don't think it's conflicting _if you insist on brackets_ after the new
expression. PHP Parser grammar for "new" expressions is
T_NEW class_name_reference ctor_arguments
If you allowed the shorter syntax, ctor_arguments would allow an
object_properties entry.
I'm sure Nikita could clarify, thou
Hi Jakob,
wt., 17 mar 2020 o 03:08 Jakob Givoni napisał(a):
> On Mon, Mar 16, 2020 at 6:48 AM Jakob Givoni wrote:
> > Let me know what you think!
>
> Thank you for your feedback so far!
>
> I'd be really curios to know what authors of the referenced RFCs think
> about this, f.ex.
> Michał (brzu
On Tue, 17 Mar 2020 at 01:47, Jakob Givoni wrote:
> Remember that the RFC explicitly says it's not an object initializer,
> nor does it solve "named parameters" which you mention.
>
I wasn't expecting COPA to "solve" named parameters, just thinking that if
we already had named parameters, we mi
On Mon, Mar 16, 2020 at 6:48 AM Jakob Givoni wrote:
> Let me know what you think!
Thank you for your feedback so far!
I'd be really curios to know what authors of the referenced RFCs think
about this, f.ex.
Michał (brzuc...@php.net), Andrey (andrewg...@rambler.ru) and Nikita
(ni...@php.net)
Is
On Mon, Mar 16, 2020 at 8:29 PM Marco Pivetta wrote:
> That kinda makes the entire feature quite useless/uninteresting to me: if a
> this does is desugaring into a set of assignments, then I'm not sure what its
> advantage is.
I'm sorry about that, but the motivation of the RFC is quite clear in
On Mon, Mar 16, 2020 at 10:40 AM Rowan Tommins wrote:
> Thanks for having another go at this feature, which I think a lot of people
> would like in some form.
I agree!
> Maybe we want to have all four, but that would leave us with a lot of
> different ways of initialising objects, which might not
Hey Jakob,
On Tue, Mar 17, 2020, 02:27 Jakob Givoni wrote:
> On Mon, Mar 16, 2020 at 9:31 AM Marco Pivetta wrote:
> > What happens if you have an expression that throws?
> >
> > class Foo
> > {
> > public $a;
> > public $b;
> > public $c;
> > }
> >
> > $instance = new Foo();
> >
> >
On Mon, Mar 16, 2020 at 9:31 AM Marco Pivetta wrote:
> What happens if you have an expression that throws?
>
> class Foo
> {
> public $a;
> public $b;
> public $c;
> }
>
> $instance = new Foo();
>
> function iThrow() {
> throw new \Exception();
> }
>
> try {
> $foo ->[
>
On Mon, Mar 16, 2020 at 9:26 AM Christian Schneider
wrote:
> [] suggests an array but then is uses literals and = instead of
> 'strings'/$vars and => which looks wrong to my PHP eye.
That's ok, square brackets are usually related to arrays and what I
want is something similar to array literals.
T
On Mon, Mar 16, 2020 at 9:10 AM Matthew Brown wrote:
> I love the idea!
Thanks Matthew!
> The syntax for new objects looks a little verbose – would it be possible to
> use
>
> $foo = new Foo()[
> property1 = "hello",
> property2 = 5,
> ];
The short answer: I don't think so.
This is not poss
For reference:
https://wiki.php.net/rfc/object-initializer
https://externals.io/message/106947
That was quite the discussion, and it started only 6 months ago.
-Mike
> On Mar 16, 2020, at 10:10 AM, Matthew Brown wrote:
>
> I love the idea!
>
> The syntax for new objects looks a little verb
On Mon, 16 Mar 2020 at 11:48, Jakob Givoni wrote:
> https://wiki.php.net/rfc/compact-object-property-assignment
> - A pragmatic approach to object literals
>
> Let me know what you think!
>
Hi Jakob,
Thanks for having another go at this feature, which I think a lot of people
would like in some
Hey Jakob,
What happens if you have an expression that throws?
class Foo
{
public $a;
public $b;
public $c;
}
$instance = new Foo();
function iThrow() {
throw new \Exception();
}
try {
$foo ->[
a = 'a',
b = iThrow(),
c = 'c',
];
} catch (\Throwab
Am 16.03.2020 um 12:48 schrieb Jakob Givoni :
> I'm opening up my new RFC for discussion:
>
> https://wiki.php.net/rfc/compact-object-property-assignment
> - A pragmatic approach to object literals
>
> Let me know what you think!
Sorry to say but the syntax look very un-PHP-like.
[] suggests an
I love the idea!
The syntax for new objects looks a little verbose – would it be possible to
use
$foo = new Foo()[
property1 = "hello",
property2 = 5,
];
as an alternative to
$foo = (new Foo())->[
property1 = "hello",
property2 = 5,
];
On Mon, 16 Mar 2020 at 07:48, Jakob Givoni wrote
Hello Internals,
I'm opening up my new RFC for discussion:
https://wiki.php.net/rfc/compact-object-property-assignment
- A pragmatic approach to object literals
Let me know what you think!
Best,
Jakob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
39 matches
Mail list logo
