Hi, I’m trying to work my way through the yellow warning triangles in our solutions. Most of them can be cleaned up by simply JSDoc’ing (is that a verb now?) the code. I have no problem doing this for simple types and known types but I am struggling with objects/structures we’ve created ourselves, especially when one object contains other objects. I’ve tried ‘faking’ as shown in the Servoy Coding Document and declaring objects but I can’t get either to work for objects within objects either. Here’s an example using ‘faking’:
/** @type {{keyA:String, keyB:String, dbRecord:JSRecord<db:/db1/my_table>}} */
var MySubHeaderStr;
/** @type {{subHeader:MySubHeaderStr, anotherKey:String}} */
var MyHeaderStr;
/** @type {MyHeaderStr} */
var _localHdr = {};
_localHdr.subHeader.dbRecord.myField = "";
When I use “_localHdr” no useful auto complete is available. It stops one level in and then proceeds to underline in yellow anything below this as undefined in type object.
Now this is just one example of the various layouts I have tried and I am sure it is simple ‘once you know’ but any pointers/examples would be much appreciated.
Alright. I’m going to play the devil’s advocate here but I feel this must be said: Is it just me or is this JSDoc thing getting more and more over the top?
I mean I like the enhanced refactoring options that feels like Java, and the auto-complete, these are really nice things to have but did Servoy really needed to turn JavaScript into a typed language to make this happen??? Can’t this all be made optional???
For me it looks like a hybrid between JavaScript and Java that is in between the best of both world, but mostly loses the best of both world: it’s not really Java because it’s not really strongly typed and you miss interfaces and all sort of Java niceties, and it’s no longer JavaScript because you are now forced to type everything!
JavaScript’s strength is supposed to be that loosely typed language, where conversion is easy and a useful thing, but this is now lost in Servoy…
I bet that if you show this kind of extra syntax you now need to add on all you custom JavaScript objects to a (client-side) JavaScript coder, he is going to tell you that this is madness. And it’s hard to disagree.
I suppose it’s hard to build a complete Object tree for auto-completion and refactoring on the fly based on non-typed objects so I know why it’s done this way, but when I look at the extra crazy syntax that’s been forced upon us, I’m not entirely sure this is always worth the effort… Until this can all be done in a simper manner, I would like to see a preference that allows to turn this nonsense off.
Having to tweak all sorts of javascript warning tags off is not a good enough option IMHO.
I agree that it’s quite a job to have everything typed and at some point I am really surprised that Servoy isn’t smarter…
for example if I type:```
var _fs = databaseManager.getFoundset(‘myDataSource’)
Why do I need to add a JSDoc to tell Servoy which datasource is bound to the _fs variable?
/** @type {JSFoundset} */
As you may notice there isn't to much difference in the 2 lines.
Don't get me wrong: I love the auto-completion in v6 and when by incident I have to code my solution in v5 I really miss it.
It also makes it way easier to see my own typing-mistakes.
But yes... when moving from a previous version to v6 it's scary to see the number of warnings.
I already experienced that solving them will help to cleanup your code and certainly get rid of some nasty bugs that make you wonder why nobody ran into them.
On the other hand A 1 click 'disable this' preference like it has been done for the performance warnings would be very helpful for those not feeling like JS-Doc'ing
Let me begin by saying that I appreciate the features of Servoy 6.
But I agree with Patrick here and let me also play devils advocate.
This JSDoc turns the loosly typed language into a typed language, but it even goes further.
For instance you want to use a variable to manage your connection name (yes I know you can use switchServer but there are use-cases where you don’t want or can’t do that).
Lets say the following dynamic code is part of your framework:
var _fs = databaseManager.getFoundSet(myServernameVar, 'tableName');
_fs.newRecord();
_fs.myColumn = 'a value';
databaseManager.saveData(_fs.getSelectedRecord());
Now in 6.0.x it requires this to please the code parser:
/** @type {JSFoundset<db:/myRealConnectionName/tableName>} */
var _fs = databaseManager.getFoundSet(myServernameVar, 'tableName');
_fs.newRecord();
_fs.myColumn = 'a value';
databaseManager.saveData(_fs.getSelectedRecord());
So now the connectionname is hardcoded into the JSDoc. Apart that it’s now in your documentation (when generated from JSDoc) I think it will actually bite you in the butt once you use this framework code in another workspace where you don’t use this specific connection name (warnings gallore).
And there are other instances as well where you use the loosly typed features of JavaScript but then the parser gets confused and you have to nail it down in your documentation for it.
And where Developer 5.2.x is very happy to complete you code in those instances now in 6 it simply plays dumb because it totally depends on the JSDoc now.
And another peeve is that the parser makes Developer much slower in comparison to 5.2.
Actually I would like to see a /** @nontype/ tag. And maybe an option that will allow me to set that (virtually) on all objects that don’t have a JSDoc.
I could toggle that on and off depending on whether I want all these objects to be reported and a quick fix to add that /* @nontype */ to it if I want it…
I very often use pure JavaScript objects that are simple collections of property/value pairs (like a Map<String, ?> in Java), for which I don’t know in advance what they will contain. This is perfectly legal JavaScript after all! So I don’t like Servoy warning me that there is an issue with that, this is just plain wrong!
Right now, I have no option for these objects but to accept these warnings or to toggle the warnings off for all.
I should be able to tell the interpreter that this is what I want.
Let me know what you all think and I’ll open an issue on the support system.
I think that tag would definitely give us more control over what we need to type or not so a +1 for me.
But it doesn’t solve the speed issue. I hope optimisations in the parser will bring it back to 5.2. speeds or there about.
and remember, a lot of us developers, (at least Robert, I know ) work with SSD-harddrive, one of the latest Intel core i5/or i7 processor, lots or memory, and still Servoy eclipse becomes slower and slower…
ptalbot:
Actually I would like to see a /** @nontype/ tag. And maybe an option that will allow me to set that (virtually) on all objects that don’t have a JSDoc.
I could toggle that on and off depending on whether I want all these objects to be reported and a quick fix to add that /* @nontype */ to it if I want it…
I very often use pure JavaScript objects that are simple collections of property/value pairs (like a Map<String, ?> in Java), for which I don’t know in advance what they will contain. This is perfectly legal JavaScript after all! So I don’t like Servoy warning me that there is an issue with that, this is just plain wrong!
Right now, I have no option for these objects but to accept these warnings or to toggle the warnings off for all.
I should be able to tell the interpreter that this is what I want.
Let me know what you all think and I’ll open an issue on the support system.
+1
I think that this is the best solution (beside the performance issue).
No surprise, I’m with devil’s advocate here 1,000%. The way I see it, Servoy was trying to accomplish a number of things:
catch developer errors earlier
better code completion
better refactor support
helping coders document
making javascript more acceptable to enterprise workshops (who generally hate javascript)
All of which I support. However, most of this is very good already in Servoy 5 and there are two golden rules of usability Servoy 6’s changes chucked into the next county:
1- make your software fast where it needs to be
2- get out of the way of the user
End result: I really really really dislike coding in Servoy 6 even though I acknowledge the motivations and have seen them help on occasion. Being 5x’s slower at key moments and being in my face all the time makes me want to kick it more often than not though. I’m one of those on an SSD and i7 and Servoy is the only app I run that tanks the processors. Like mouse-is-unresponsive-for-several-inexplicable-seconds-tank-the-processors.
Add another issue to the list: JSDoc params automatically write themselves into your function declaration if the param is missing there. Never-ever-EVER do I want documentation or comments automatically generating code for me. That’s what coding is for and if the dev can’t code, then that’s their problem. The solution isn’t writing code for them.
Servoy 5 has an awesome editor with great refactoring, code completion and code snippets. Why mess with it in such a major way? With the current trajectory, are we going to be waking up to Servoy 6.1 needing to write interface boilerplate and JUnit tests before we can actually get to coding?
What we really needed in Servoy 6 was the Javascript Rhino engine to be upgraded. It’s years out of date.
Instead of trying to put javascript in a box where it doesn’t belong, in my world I would remove most of the new cruft, keep the rhino javascript engine up-to-date and look at adding support for other languages such as groovy and jython.
I am not as sophisticated developer as some, but my comments are:
I do find eclipse and servoy very slow on a mac. I am also using i7 on a macbook air and it is like i never upgraded from my last air. Most of the time when i am in my office where my solution is deployed, I actually refrain from doing any heavy changes or development and just take notes so i can do it at home. However at home on a rebooted MacPro with 6gig and a quad core processor, and it still has tis issues, often needing to be restarted as it runs so slow.
Whilst I understand the warnings, it is somewhat depressing have 4000 of them, and on some things like getting a found set, it seems a little trivial to have to find that extra line of code to remark in order that they don’t appear.
For me the speed of the developer is the biggest problem, and i think it is slower in 6, although 4 and 5 have their issues to. This may not be entirely a servoy issue, but for me anything to speed up the developer would be very welcome.
From my point of view: JSDoc should be an enhancement for coding and helper tool for development, not a requirement.
So I agree on making JSDoc optional.
But isn’t there a way to generate -most of required- JSDoc syntax in our dear code? Something like a ‘Generate JSDoc’ button or something in the Servoy Design perspective?
The slew of warnings is certainly alarming as a Servoy beginner, until you investigate why they’re happening, but so far I have found the requirement to JSDoc things adds quite a few benefits. I don’t see any particular speed issues with Servoy 6, having said that I suspect my projects may be quite a bit smaller and simpler than those of a lot of the old Servoy lags!
Having a switch for it definitely sounds like a win-win though.
OK, so basically it seems most people agree that this JSDoc constraint can be a nice thing, but is also a nuisance.
Most agree that it should be easy to turn off entirely.
I also think that a /** @nontype */ tag is necessary for those case where you want your object to be plain Objects and not have any warnings about them.
I’ve seen no reply from Servoy though… So I’ve created a feature request on the support system: https://support.servoy.com/browse/SVY-1829
Please vote/comment there as well.