> On Sep 14, 2019, at 4:47 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
> I think that's only true because you've actually proposed a number of related
> but different features.
See my other email to the list asking about what is in-bounds and what it
out-of-bounds regarding RFC discussion.
I seemed logical to me to discuss how to improve an RFC, but maybe what you are
saying is that we are only suppose to discuss RFC as it exists today in order
to give a black and white, up or down vote on the entire RFC? That seems
counter-productive, but if that is the case and others concur then so be it.
So to be safe, I have started a new thread for this reply.
> other than initializing additional objects. And if these are additional
> objects, then named parameters work just as well in the nested case as in the
> non-nested one:
>
> $car = new Car(
> yearOfProduction => 1975,
> vin => "12345678",
> engine => new Engine(
> type => "v8",
> capacity => "270ci",
> ),
> );
Obviously that can be done. However, in practice I often see arrays used
instead of objects because it is so much easier. I doubt that this enhancement
will remove the other reasons developers might continue to use arrays instead:
1. Arrays do not require a developer to name a class, where naming is one of
the 2 or 3 hardest parts of computer science
2. Anonymous classes are more tedious than just creating an array literal so I
see most PHP developers using arrays instead.
3. Defining a class in PHP best practice means creating another file that is
physically separate from the code for said class that must also be
(auto-)loaded.
So are you arguing that in all cases where people want structured information
they should create a new class, and if so, what about the three points I just
made?
> This already works:
>
> $stats = new class {
> var int $total = 0;
> var int $mean = 0;
> var int $average = 0;
> var int $median = 0;
> };
>
> What doesn't currently work is using variables from lexical scope in the
> definition:
>
> $stats = new class {
> var int $total = $a + $b;
> var int $mean = $c;
> var int $average = $d;
> var int $median = $e;
> };
In the USA we have a saying:
"Besides that Mrs. Lincoln, how was the play?"
But for those unfamiliar with US history leading up to the revolutionary war,
what it means in this context is:
"Yes your point is correct, but ignores the most relevant concern."
> However, initializer syntax on its own doesn't solve this, because you
> wouldn't be able to specify the types for the properties; just combining
> existing syntax with initializers would give something like this:
>
> $stats = new class {
> var int $total;
> var int $mean;
> var int $average;
> var int $median;
> }{
> total => $a + $a,
> mean => $c,
> average => $d,
> median => $e
> }
You probably missed that I wrote that I was using an alternate initialization
syntax that I would propose instead, which I will illustrate again below. If we
allow typing i
$stats = new class {
int $total = $a + $b;
int $mean = $c;
int $average = $d;
int $median = $e;
};
> You could certainly make the syntax of initializers and anonymous class
> definitions similar, but they're not really the same thing.
Noted. To me them being the same or not is not as concerning as the outcome of
the features that may become available in userland.
> The QueryBuilder class in this example has not benefited from object
> initializers at all; passing the Query object rather than separate parameters
> is a refactoring you can (and probably should) do right now.
But many PHP developers are unlikely to do that refactoring initially. They
will just fall back to using arrays, because they are easy, comfortable, less
pedantic and less tedious to use.
I would far prefer to have find developers using untyped anonymous objects than
arrays because the former is much easier to refactor to better code than the
latter, and this is painfully obvious to me because of numerous PHP codebases I
have been brought in to fix.
Would it be better to introduce a simple-to-use object instantiation syntax so
userland PHP developers would start using it, or would it be better to leave
them only one easy option such that they continue to use arrays?
> As before, the definition of the class itself is simpler, but I think a
> short-hand syntax for constructors would be a better compromise than a syntax
> that only worked with public properties and parameterless constructors.
My problem with short-hand syntax for constructors is they only work in context
of constructors.
What about other functions or methods that userland PHP developers currently
pass structured arrays too?
> This is an interesting additional proposal, which I admit would be awkward to
> implement without initializer syntax. One limitation is that it only works if
> dependencies are declared as concrete classes not interfaces
True.
If a function is defined to accept an interface then the caller would be
required to pass in an instance of a class that satisfies the interface.
> which like public properties is not "wrong" per se, but limits the scope of
> the feature.
If we had to have every feature work for everything, we'd never have `foreach,`
for example.
My belief is that not every feature needs to apply in all contexts in order to
be highly useful. Do you believe otherwise?
> Named parameters are (or would be) a way of setting a bunch of variables;
> they're not linked as an object of any sort, so I don't think there's a
> natural comparison to anonymous classes at all.
I did not say they _were_ linked, I asked why couldn't/shouldn't they be linked?
They are both a group of named "properties" with associated values. Why are
they all not equivalent to an object?
And why not allow all of them to be treated as an object?
Even if there are represented different internally, I see no reason why they
could not be made equivalent in userland code. Do you?
> If I understand it right, the next example relies on the combination of
> anonymous class initialisers, named class initialisers, and named parameters
> all using the same syntax,
No, I would say that is not what I am proposing. What I am proposing is that
one syntax and one set of functionality be used to address all three use-cases
rather than have three different functionalities with three different syntaxes,
because they seem to be to be all equivalent:
1. anonymous class initialisers,
2. named class initialisers, and
3. named parameters
As Larry Garfield said, we are running out of sigils; making one syntax address
multiple use-cases seems to me like the most responsible thing to do.
> The examples look really neat on their own, but imagine coming on that syntax
> in someone else's code and trying to work out what it was doing.
If I see someFunction({bar => 1, baz => 2}) that tells me that someFunction
expects bar and bar as integers. When calling functions we are not supposed to
know how they are implemented, so why should it matter to the caller whether
internally they are captured to individual parameters or into a single
parameter array? And when inside the function, why does it matter how they are
passed?
The reason I proposed this is I would really prefer to come on to this syntax
in other's code rather than coming onto the prevailing type of code I see in
userland instead; arrays upon arrays.
What is not clear to me is why you see it to be confusing?
> There's definitely some interesting ideas here, but they're not all part of
> one feature,
Can you clarify what you are implying? That I should start other threads to
discuss? That I should create new RFCs?
> and they all rely on particular ways of structuring your code.
Is that problematic? Most language features require code to be structured a
particular way.
I am assuming that PHP is not an opinionated language that defines one way to
structure code and shuns all other ways, except for those ways that have been
explicitly deprecated by RFC such as magic quotes. Am I incorrect about this?
-Mike
