I see that some IDE like (PHPStorm) can read phpDoc in code I mean when i do
/** #var SomeType $variable */
$var = $this->diffrentWayToCreateAnObject('SomeType');
or my best
/** #var SomeType $val */
foreach($item in $key => $var) {
}
PHPStorm knows that $var is an instance of class SomeType. This is very handy when I work using diffrent frameworks cause I don't always create an object using new keyword
Can I make my eclipse to read this ?
I've been told by several other Eclipse users before that PDT does recognize this usage of #var, although I myself have never actually seen it succeed.
One syntax change that might help your usage would be to use a fully qualified namespaced name for your data type:
/** #var \SomeType $var */
$var = ...
Note also that I corrected your variable name in your example. If that example is actually your code verbatim, the variable name mismatch ($variable vs $var) would explain why the #var did not work.
I see the same two issues in your foreach() example too, "SomeType vs \SomeType" and "$val vs $var).
Related
I want to do jsdoc with something like the following
/**
#param {string|number[]}
*/
In the above it's an array of numbers or a string, but I want an array of numbers and/or strings. I need this to work for other things like 2 different kinds of objects. Does anyone know how to do this?
If you are using Closure Compiler, you can write:
/** #param {!Array<number|string>} x */
function f(x) {}
See this example.
Inline Documentation (use Ctrl+Q to open it's pop-up) in IntelliJ IDEA (2016.3.4) is having problems when JavaDoc contains variables, like:
/** Selects the first element of this $coll.
* $orderDependent
* #return the first element of this $coll.
* #throws NoSuchElementException if the $coll is empty.
*/
Instead of parsing these variables it displays: [Cannot find macro: $coll.]. Scala API parses it correctly and changes $coll into iterable collection.
Is there a way to fix this issue in IntelliJ IDEA?
It's a known bug in IntelliJ IDEA Scala plug-in:
SCL-9720 Documentation view unreadable when #define placeholders are used
Sorry to bother the community for this but I have unfortunately to code in Perl :'(. It is about an OO perl code I want to understand but I am failing to put all the pieces together.
The following is a template of code that represents somehow what I am currently looking at. The following is the class MyClass:
package Namespace::MyClass;
sub new($)
{
my ($class) = #_;
$self = { };
bless ($self, $class);
}
sub init($$)
{
my ($self, $param1) = #_;
$self->{whatever} = ($param1, $param1, $param1);
}
and then the following is a script.pl that supposedly uses the class:
#!/path/to/your/perl
require Namespace::MyClass;
my myClass = new Namespace::MyClass()
myClass->init("data_for_param1");
There may be error but I am interested more in having the following questions answered than having my possibly wrong code corrected:
Questions group 1 : "$" in a sub definition means I need to supply one parameter, right? If so, why does new ask for one and I do not supply it? Has this to do with the call in the script using () or something similar to how Python works (self is implied)?
Question group 2 : is for the same previous reason that the init subroutine (here a method) declares to expect two parameters? If so, is the blessing in some way implying a self is ever passed for all the function in the module?
I ask this because I saw that in non blessed modules one $ = one parameter.
Thank you for your time.
QG1:
Prototypes (like "$") mean exactly nothing in Method calls.
Method calls are not influenced by prototypes either, because the function to be called is indeterminate at compile time, since the exact code called depends on inheritance.
Most experienced Perl folk avoid prototypes entirely unless they are trying to imitate a built-in function. Some PHBs inexperienced in Perl mandate their use under the mistaken idea that they work like prototypes in other languages.
The 1st parameter of a Method call is the Object (Blessed Ref) or Class Name (String) that called the Method. In the case of your new Method that would be 'Namespace::MyClass'.
Word to the wise: Also avoid indirect Method calls. Rewrite your line using the direct Method call as follows: my $myClass = Namespace::MyClass->new;
QG2:
Your init method is getting $myClass as it's 1st parameter because it is what 'called' the method. The 2nd parameter is from the parameter list. Blessing binds the name of the Class to the Reference, so that when a method call is seen, It knows which class in which to start the search for the correct sub. If the correct sub is not immediately found, the search continues in the classes named in the class's #ISA array.
Don't use prototypes! They don't do what you think they do.
Prototypes in Perl are mainly used to allow functions to be defined without the use of parentheses or to allow for functions that take array references to use the array name like pop or push do. Otherwise, prototypes can cause more trouble and heartbreak than experienced by most soap opera characters.
is what you actually want to do validate parameters? if so then that is not the purpose of prototypes. you could try using signatures, but for some reason they are new and still experimental. some consider lack of a stable signatures feature to be a flaw of perl. the alternatives are CPAN and writing code in your subs/methods that explicitly validate the params.
I want to use doxygen to document a c-like language.
I got some issues to solve keywords which are unknown in the context.
One example, I have to use a callback function called
on timer
{
//normal c- code
}
My question is now, can I adopt doxygen to accept the new keyword?
I would like to add this keyword like a function or variable acc. to
/** This timer is used for something. */
on timer
{
}
or maybe
/** \ontimer This timer is used for something. */
on timer
{
}
The documentation of doxygen describes something with ALIASES or \xrefitem but as I understand I can only generate new sections for known types or am I wrong?
Actually I am surrounding the unknown code with a condition block out to avoid errors in the generated output.
As I understand is "on" a keyword which doxygen cannot interpret. One solution could be to declare the keyword on as a predfined macro in the doxyile by using the the PREDEFINED tag as follows:
PREDEFINED = on=
Yes, the = at the end is not a typo! This tells the preprocessor of doxygen to substitute the keyword on with a empty string. Note that you have to set ENABLE_PREPROCESSING to YES.
If the on keyword only appears before callback functions you could alternatively set the PREDEFINED macro to void:
PREDEFINED = on=void
Using Eclipse Helios:
If I define a simple Javascript function
/**
* #returns {Number}
* #param {String} arg
*/
function test(arg)
{
return 1;
}
the tags were those automatically added by Alt-Shift0J - then the inferred type for the function is:
Number test(any arg)
Parameters:
{String} arg
#returns
{Number}
Note the "any arg", despite also Eclipse also recognising the parameter is "{String} arg" later.
Nothing I've tried get the inferred type of the arg to be anything other than "any". This means calling the function with a non-String isn't detected, which is a pity.
So, is this a bug? Not supposed to work? Something I'm doing wrong?
Actually the JsDoc annotations in JSDT/Eclipse are meant for primarily two reasons(as per my comprehension, do correct me if its not the same)
For generation of documentation and
To let eclipse-JSDT-engine help the developer with auto suggest(case-specific).
so the eclipse-developers are not just cross-checking the annotation bindings with your actual code implementation until you run the js file. And again, while you run the javascript. at run time the the javadoc annotations are overlooked as mere comments.