This grinds my gears on a few levels - I really don't feel as though the reaction here is a resistance to change, as much as it is a resistance to completely redefining pretty much all of the core language constructs.
The Snow code is, in my eyes, almost completely unreadable, due to a seemingly random collection of characters.
I'm a PHP developer, and while I appreciate that (at times) PHP can be quite verbose, introducing such sweeping changes really doesn't make any sense to me. The add_row() function in particular is mind-bending for me. Auto-declaration (and initialisation, within a loop, no less) can only hurt in larger systems - which is why developing with notices enabled is such a plus.
I get annoyed with the php community because this thread embodies what a typical response from them is like. Criticize anyone trying to do something new by saying the old ways are best without giving any constructive feedback.
Also note. No one has to use Snow if they don't want to. These are not changes to the core of php, so it confuses me why people get so militant over the suggestion of a DSL for php.
As for your feedback itself - your own suggestions don't appear to improve readability in any meaningful way, mainly because the underlying example is simply so unreadable already.
I'm perfectly happy to debate potential layers above PHP to help with speedy development, but I'm also perfectly happy to argue against those that I don't believe have any promise.
> The concatenating assignment operator "%=" shouldn't change. It should stay the same ".="
The reason for using "%" was that I wanted to use "." for objects:
instance.my_method()
I don't think "%" will be used as much due in Snow, due to the new "smart strings": "{a_variable} and {a_method()}"
> Accessing instance variables/methods should be by using '@' rather than '.' as that is becoming an
> implied standard and php folk are already used to using '.' for string concatenation.This looks weird, no:
@instance@var@subvar@sub_method()
and what about accessing static vars and methods?> The setting of parameter types and defaults on methods is too heavy and not what people expect. I would put them back into method declaration.
Yes it's heavy, but as you always need to have a docblock to write "acceptable" PHP code, I chose not to duplicate the argument names.
> This doesn't make a lot of sense.
No this should go, I decided that a couple of weeks too. But the problem its trying to solve is a real one. Your proposal looks good, but how would it work on a new variable?
You should expect criticism and taking is by falsely accusing the whole huge community of "resisting any change" is exactly the wrong way to do it.
I think the best part of the pre-processors is that it does not force the entire community to adopt the syntax and allows some to play with new language features.
What I like:
- The new return "<-"
What I think should change:
- The concatenating assignment operator "%=" shouldn't change. It should stay the same ".="
- Accessing instance variables/methods should be by using '@' rather than '.' as that is becoming an implied standard and php folk are already used to using '.' for string concatenation.
- The setting of parameter types and defaults on methods is too heavy and not what people expect. I would put them back into method declaration.
- This doesn't make a lot of sense: Good work on what you have already achieved, with a bit of extra polish I think Snow can become very desirable.