Re:PHP-Snow - A concise, dry and beautiful language that com...
by runekaagaard on Monday March 26, 2012 @03:21AM
(#3755506)
Thank you so, so, so much for actual constructive criticism!!!
> 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?
> The concatenating assignment operator "%=" shouldn't change. It should stay the same ".="
The reason for using "%" was that I wanted to use "." for objects:
I don't think "%" will be used as much due in Snow, due to the new "smart strings": > 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:
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?