traq;11021687 wrote:I think many of the examples you give are over-simplified: you often ask "if x should be done to improve type safety" - but you don't necessarily explain how x will be implemented.
Fair enough. I see what you mean and I see, that it is difficult to choose an option if one think about it as you have done. I have explicitly left out any implementation, since the survey would be even longer with it and honestly, I think now that it is already too long, I should have shorten the survey a little bit. First of all I have thought about implementing a very strict model which would have needed an explicit casting. For instance a method call would have been
int $a = 1;foo( (string) $a);
However, I have made some speed tests and have realised, that explicit casting is slower in PHP than the PHP intern casting. For instance:
$a = 1;
$b = (int) "1";
$c = $a + $b;
is slower than
$a = 1;
$b = "1";
$c = $a + $b;
Therefore I am not yet sure how I am going to implement it.
traq;11021687 wrote:
...Does it cast $str to a string, but only if $str == (string)$str?
(...BTW, this is the answer I would have chosen)
I am not sure if I really get what you mean. Take your example with an integer. For instance:
function foo(int $i){
echo $i;
}
$a = "a";
foo($a); //output = 0 since $a == (int) $a;
Is this really what you want? Or would your behaviour only be applied to strings?
traq;11021687 wrote:
Regarding templates, I think the best (simplest, most obvious) solution would be to create a template object and pass (or [font=monospace]use[/font]?) the desired variables directly to it.
I agree, that would be the simplest way, but I believe developers are still heavely relying on templates (including other files). I mean, it is already possible to use objects instead of including files (needless to say that classes will also be included at a certain point) but one like including files without context more than defining classes and using them. I undestand them, since including files is quite convenient.
traq;11021687 wrote:
Dynamic typing is a benefit, not a shortcoming. Full type safety would completely break many PHP applications. I'm not advocating that backwards-compatibility should be the deciding factor, and while a measure of type safety (or perhaps type hinting and stricter control over type coercion is what I really mean) would be beneficial, it could also lead to unnecessarily complex code.
I absolutely agree. Type-safe code leeds often to more complex code than unsafe code. I think one good point in my approach is, that I introduce TSPHP at a higher level. PHP is still available as it is now and for certain web applications it is more appropriate to use PHP rather than TSPHP. And since TSPHP is translated into PHP one can develop his component in TSPHP and another one show use PHP can use the component (unfortunatley not the other way round - but if TSPHP is usefull as I expect it to be then I will probably also develop a type inference system which transforms PHP into TSPHP as far as possible). However, especially bigger projects which underlies many changes (over the years) are quite painfull to maintain, because refactorings for PHP is poorly supported by IDEs and quite error prone. If you have done ones a refactoring in type-safe languages you exactly now what I mean. And in my opinion refactoring is very essential to keep your code quality high over the years and changes.
traq;11021687 wrote:
As an example, [font=monospace]$GET[/font] and [font=monospace]$POST[/font] are always initially strings - do you intend to initially cast them to a "best fit" type? According to what rules? Or would one be forced to write constructs like
function whatever( int $int ){ /*...*/ }
$result = whatever( ((integer)$_GET['userInt']) );
?
Well, as said above, first of all I intended to implement a very strict model, but now I guess I will accept some operator overloadings. For instance
string $b="1";
int $a = 1 + $b;
will be valid, since + automatically casts strings to integers. However, I am not yet sure how I will implement it for parameters. I was thinking about a strict model (thus (integer)$_GET['userInt']; whould be necessary) but with the option of an automatic casting. Anyway, I haven't made final decision yet.
Those questions should have been skipped when you choose no your opinion hasn't changed.
