> On Mar 10, 2020, at 8:33 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
You make it really hard to just let the discussion just stand.
>> Consistency with other declarations in PHP?
>
> I think this is generally a weak argument, because we have a mixture of
> punctuation and keywords already.
Saying it is a weak argument is merely opinion. You are grasping for reasons to
claim that.
Yes we are talking opinion on both sides, but you are presenting your opinion
as somehow more authoritative with the "weak argument" claim. To wit...
> We use { and } to denote blocks, not begin and end keywords;
Begin and end are not declarations in any language. Those are statements to
delineate blocks of code.
> we keep on adding operators because people prefer them over function syntax;
> and the biggest complaint with the lambda syntax
> was that people wanted to *remove* the "fn" keyword.
Those are closures for anonymous functions. They represent a callable value,
they are not declarations of named symbols nor references to named symbols.
> You mention properties as not having sigils, but we don't have a "property"
> keyword either; we have an optional "var", but I'm not clear why that was
> un-deprecated, because the syntax "visibility $name" is always sufficient.
Pedantry notwithstanding, clearly I was speaking of "public", "private", and
"protected" (as well as "var", but I know that most PHP prefer the visibility
modifiers instead.).
All of those are keywords.
> And although we write "class Foo extends Bar" where other languages would
> have "class Foo: Bar", we write "function foo(): Bar" rather than "function
> foo() returns Bar"
Minimally because we need the terseness in type hints for parameter lists.
It would be inconsistent to use colon in parameters lists and then `returns` in
function declarations.
> and there are people who would prefer to write "public foo() {}" rather than
> "public function foo() {}".
Makes sense where it can be unambiguous. Note that there is still a keyword
there, not a sigil.
> think it makes more sense to evaluate the syntax *for this specific case*,
> rather than trying to compare it to other decisions we've made in the past.
Sorry, but that feels really ironic. You point me to past decisions when it
support your argument, but when it does not you suggest that we evaluate "for
the specific case."
>> Just because other languages did it that way? That seems like it is just
> a bandwagon justification, not a justification based on evaluation of
> available options.
>
> We should learn from other languages rather than blindly copying them, but
> it's interesting that I've yet to see one which adopted a keyword-based
> approach.
This one is true. All other C-based languages appear to use @Foo, or [Foo] for
C#.
But we can't use those. And since we can't it is not clear why we could not
consider keywords just because all other languages had the @sign or the []
available.
> That means either:
>
> * They didn't even consider a keyword approach
> * They considered a keyword approach, but rejected it for reasons that
> don't apply to PHP
> * They considered a keyword approach, but rejected it for reasons that we
> should at least consider
>
> Before we go down the path of being the one language which does it
> differently, we should at least examine which of those is the case.
Most likely because Java chose "@" so most everyone copied it. And the
languages that did not use @ are generally for the more advanced developers.
Whatever the case it does not seem to me that this is the type of case where we
could really go wrong no matter which we pick. Either sigils or keywords would
work, it does not seem like something that needs exhaustive research.
That said, as it seems I am the only one on the list who has commented that
really dislikes this syntax I will let this die if you can just let it die too
because at this point we are both bikeshedding.
-Mike
P.S. Another approach would be to use at-sign+colon. e.g. "@:Foo"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
