On Tue, 10 Mar 2020 at 11:46, Mike Schinkel <m...@newclarity.net> wrote:
> > On Mar 10, 2020, at 7:36 AM, Rowan Tommins <rowan.coll...@gmail.com> > wrote: > > I think that applies to our case equally: any punctuation or keyword is > > just a separator between the main function declaration and the specific > > attribute being applied. Having to write "attribute Sealed" would be like > > having to write "visibility public"; as much as possible, we want > "Sealed" > > to be the keyword, and the rest of the syntax to just be formatting. > > No, you are making a flawed comparison. > > There are only three (3) visibility modifiers in PHP whereas there are > practically *infinite* potential attribute classes. > Yes, it's a slight exaggeration, I was just trying to expand on the quote from Guido van Rossum; you can read his full response here: https://mail.python.org/pipermail/python-dev/2004-September/048518.html His example actually uses the infinite variety of decorators as a reason to minimise the syntax: > A classmethod or staticmethod decorator adds a completely different flavor than a decorator that provides an > external linkage hint for ObjC, or one that adds synchronization, or one that declares deprecation. Anyway, the main reason I linked the Python discussion was to see what talking points were raised, and that was pulled out in the PEP and I thought was interesting. > > That doesn't mean PHP couldn't buck the trend and use a keyword instead, > > but we'd need a strong reason to do so. > Clarity? Readability? Ease of learning? Sure, if people agree it provides those things. I personally don't, but that's fine, not everyone's going to agree. > Consistency with other declarations in PHP? I think this is generally a weak argument, because we have a mixture of punctuation and keywords already. We use { and } to denote blocks, not begin and end keywords; 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. 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. 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", and there are people who would prefer to write "public foo() {}" rather than "public function foo() {}". I 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. > 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. 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. Regards, -- Rowan Tommins [IMSoP]
