[size=15]
3. No types support: (this is the main problem)[/size]
There isn’t a notion of types currently! Instead of them you define and use an absolutely inappropriate here «var» type for everything.
This approach is fundamentally wrong: PHP defines the following data types (
http://www.php.net/manual/en/language.types.intro.php): boolean, integer, float (floating-point number, aka double), string, array, object, resource, NULL, mixed, number, callback.
The miss of the types causes at least 4 problems:
[size=14]
3.1)[/size] One needs to add the mentioned above types for each project again and again and that’s awkward and takes time.
Why don’t you add all those types at once (excluding NULL) and use «mixed» instead of «var»?
[size=14]
3.2)[/size] After adding the types manually and generating the code one gets the syntax mistakes as a result. This happens because the type parameter is not considered in generation and as a result we get:
public function test(boolean $a = true)
{
}When actually it is allowed to mention as the type ONLY
«array» and the class name.
The template of parameter generation («Parameter») needs correction.
[size=14]
3.3)[/size] There are inconveniences when model is synchronized with the code.
There is a following class diagram:
Make the «Class1» [ch1089]lass generation, and now let’s try to synchronize the model and the code (highlight the class and press F7):
Caution: all the information about the parameter type in “Class1::test()” is lost. The diagram is damaged - great!
[size=14]
3.4)[/size] Let’s take another class diagram
Making the code generation (highlight the class and press F11)
.....
/**
*
* @param a
*/
public function test(boolean $a = true)
{
}
.....Correcting:
.....
/**
*
* @param a
*/
public function test($a = true)
{
}
.....Highlighting “Class1” and pressing F11 again:
As a result we have to manually make correspondence between the test() methods in model and in code.
In case of large classes this procedure VERY soon becomes VERY annoying. In spite of doing really useful work one needs to spend his time on this rubbish…
The problems described here later are partly caused by the lack of PHPDoc support (see later).
[size=15]
4. No PHPDoc support[/size]
Currently, to make the comments while code generating one needs to use «%JAVADOC_COMMENT(genOptWrapComment)%» - this is not correct, because “javadoc” and “phpdoc” are significantly different!
For details see:http://manual.phpdoc.org/HTMLframesConverter/default/
The creation of this kind of support will let everyone to get rid of some problems mentioned in the “No types support” section.
It would be great also to add the support of the tagged value “throws” as it is done in Java – and, of course, not to forget to add it to comments (@throws).
Yeah, one surely can put that all in manually, but when importing, all this stuff becomes useless; moreover: doing so will lead to comments pollution as the parameters definitions would be again and again added to them.
Show Posts
