RE: [Jsdoc-user] some questions regarding jsdoc

[<tob...@or...>]

hi gabriel

thanks for your quick reply.

> I've just fixed this problem, thanks for reporting it. A while back I
> added a step in the preprocessor to shrink down all string literals
> to avoid problems that were occurring with segfaults in some builds
> of perl, without noticing that it broke this functionality. I've
> removed that preprocessor step, as I'm now encouraging people to get
> a build of perl that doesn't segfault on recursive regexes instead of
> trying to work around it in JSDoc.

great! i certainly encourage you to avoid fixing other people's bugs.
(but sometimes it just has to be :)

btw. when do you plan to release the next version of JSDoc?

> For the moment, global variables like this are simply ignored.
> There's been talk of adding a '@global' tag or something similar to
> tell JSDoc to add these to the global class, but I haven't
> implemented it yet. I'd say it's coming, but I can't say when
> exactly.

is there a pointer to follow this discussion? it's just that i cannot=20
think of any good reason at all why such globals should be excluded=20
from a documentation...

> If two versions of function bar are in the same scope as shown above,
> only one of them will be available at execution. JSDoc can also only
> handle a single version of a function with a given name, although I
> believe JSDoc will take the first version it find, as opposed to a JS
> interpreter, which will take the last. Or am I missing something?

nope, you're totally right. this is kind of a speciality of hop, the=20
application server we are using. script files are located in=20
directories which determine the prototype (or class) they belong to.=20
this way, we can define a method bar() in two (or more) directories,=20
say Foo and FooBar, and make them instance methods of different=20
prototypes. (it's not really good practice anymore and we are=20
currently elaborating on that, anyway).

but i don't want to bother you with such details. it's just that i=20
thought it would feel natural if JSDoc was to take the @member tag with=20
a higher priority and document a method according to it -- just as it=20
takes e.g. @extend simply as is without further checking if there really =

is such a parent class...

ciao,
tobi


ps. sorry for the list-inadequate layout of my first e-mail... i hope
this one's better now.