Javascript Developer Tools (JSDT) for Eclipse provides a nice outline view of Javascript classes, with a little symbol next to them to indicate visibility.
Looking at Preferences->Javascript->Appearance->Members Sort Order, it seems able to indicate whether a method is public, private or protected, but all of my use the "default" marker, a blue triangle.
Does anyone know how it determines which symbol to use? I've tried using Javadoc and JSDoc formatted comments. My private methods start with a leading underscore, and that doesn't give it a hint either.
Not a big deal, just would be nice to know...
Seems that it is just a standard Java-based settings tree (used in many plugins) but without real implementation of JS private members stuff. Oh, we can hope that it is reserved for future use :)
There's no syntactical way of making a method private, public or protected in JavaScript, it strictly relies on where the method is defined (scope).
Marking a methods privacy is something else, there really isn't a standard for that. All I've ever heard of is the "underscore" for private members. So maybe JSDT doesn't implement this.
I believe there is a #private annotation supported by JSDoc. Not sure how standard it is, or whether JSDT supports/enforces it.
Since JSDT is a reimplementation of the JDT interfaces, it may just be reusing JDT's private/protected/public model best it can, without an actual way to mark fields/methods for access control.
Related
What is encapsulation in context of JavaScript? I'm confused after reading this statement in mozilla web-site(link):
Encapsulation
In the previous example, Student does not need to know how the Person
class's walk() method is implemented, but still can use that method;
the Student class doesn't need to explicitly define that method unless
we want to change it. This is called encapsulation, by which every
class inherits the methods of its parent and only needs to define
things it wishes to change.
I've understood encapsulation as hiding class members, but in the example on the Mozilla site it seems to be simple inheritance.
It means that you don't have to be able to build the tools that you're using to use them.
It's makes programming a lot less stressful when you can abstract things like that away.
Have you ever used the alert() method in JavaScript?
I'm sure that you'd feel a bit overwhelmed if you had to care about how alert communicates with your browser, and how your browser communicates with your display and all the layers in-between.
You don't want to worry about the bezier curves used to render your fonts or how to implement the ok button, or all the other code that makes alert work. All you know is that you can write alert("txt") in JavaScript, and that a dialog box will appear.
walk is implemented in Person. Student isn't allowed to change how it's implemented, it can only override the function completely.
You could design a programming language that allows you to override parts of the parent function rather than the function as whole. This programming language has inheritance but not encapsulation.
Now of course if a child overrides part of a parent function, this means the child and parent implementations are coupled. This is generally considered bad practice. This is why most languages go so far as to enforce encapsulation, but it's not something you absolutely need.
Maybe a good analogy is a plugin mechanism. You can write plugins in different ways: use some event hooking or use clever inheritance but you can also do inline code replacement. Now before you think this is ridiculous, older versions of the popular forum software phpBB actually did this. You can imagine what happens if you install two plugins that might interfere, there's no telling what will happen!
Can anyone tell me if it's possible to use JSDoc on JavaScript (more like ECMAScript) with some additional features? For example, I have code like this:
function(a : String, b : Number) : Object {
// do some stuff here
}
As you can see it's almost JavaScript but with possibility to specify type of arguments and return value. So can I somehow use JSDoc on this syntax? Is there any method to write some kind of plugin for it?
Thanks.
Sorry, I was on my phone earlier, I can answer in a bit more detail now.
To start, I think you're confusing JSDoc with its implementations. JSDoc is just a standard way for people to document Javascript code. In and of itself, it isn't a program and it doesn't do anything. Now, there are certain programs that are aware of JSDoc and provide certain features based on it. For example, an IDE might show JSDoc when hovering over a method. So if you wanted to, you could use JSDoc anywhere you wanted, including in code for different languages. However, if you wanted programs that take advantage of JSDoc to recognize it, you have a bit of a problem.
I highly doubt any current JSDoc programs are going to recognize the format in any language except strict Javascript. I downloaded jsdoc-toolkit and it's definitely true of that one, and probably true for most of them. If you really want JSDoc for that code, you'll probably have to write some kind of program (or edit one) yourself. Unless this superset of ECMAScript is a common language, in which case there might be a program out there.
What is best practice for naming custom property in ExtJS?
Is it a good idea to precede name with an underline?
Ext.create("Ext.Window,{
height:50,
_custom:"xxx",
_action:"yyyy"
});
another idea is using data_ prefix to mimic html5 custom attribute convention.
I personally don't like anything in a variable name that carries additional syntactic information (Uncle Bob dedicates a whole section to this principle in http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882), not to mention the ugly code it produces (e.g. mywindow._custom).
I would just give your variables descriptive names, and then your code will read better and you shouldn't have to worry about collision with Ext properties (if you were worried about).
I like this much better:
Ext.create("Ext.Window,{
height:50,
customNameOfSomething:"xxx",
actionToPerform:"yyyy"
});
Agreed with others, and will add that the underscore in particular is more or less an accepted standard for private variables in most syntaxes (though Ext JS itself does not use it, and keeps private variables marked as private via comments or undocumented by convention). I definitely would choose some other way to name public configs if you insist on choosing some convention, though I agree with others that it's probably not necessary. I would guess that in most real cases, your custom properties are not going to be so generic as to clash (and if they are, you probably chose poor names for whatever you're adding).
You have to remember that you're designing a custom property that might be used by others. This means that it has to be descriptive of its behavior. That's what is most important. Using an _ is very rare and isn't really natural to developers using the code, so it's gotta be user friendly.
I decided to to use _ as a prefix for custom variables. because:
It prevent any collision
Self-documenting
It's users friendly
It would be better if Sencha used a mechanism to prevent the mixing up.
I know that JavaScript doesn't support private members, but you can emulate those. I'm wondering here is that if it's worth it. Is there a point in making variables and/or functions private in JavaScript?
Is there a point in making variables and/or functions private in JavaScript?
I would argue ‘no’... and ‘no’ in more languages than merely JavaScript.
Information-hiding and encapsulation is all very commendable, but unless you have security boundaries inside your application, you don't actually need to enforce privateness with strict language-level limits. Who is the untrusted attacker you're protecting your code from? Yourself? Others in your team?
In a Java environment you might theoretically be writing a class to give limited access to a resource to a sandboxed party like an applet. In that case you wouldn't want the applet code to be able to mess with private members as it might transgress over a security boundary.
But in JavaScript this isn't possible. You get one security context per host:port and you can't create effective security boundaries to limit code that shares your context. The ability to hide a variable is pretty meaningless when any JS code can completely take over the page's UI. (Plus, some browsers have occasionally had features that defeat private variables, for example Mozilla's old, now-removed __caller__.)
Consider instead the Python way: have a convention for effectively-private, even if the language doesn't enforce it. Putting an underscore at the beginning of a member name is warning enough that class-users shouldn't be messing with that member, but doesn't make yourself a load of annoying extra work when you're debugging or prototyping and need to temporarily ignore the privateness.
Here is the stackOverflow answer about how to do this in circumstances when you would want to:
JavaScript private methods
And here is an article about signing that does include an expert's quote:
'On the other hand, because JavaScript has no concept of public and private methods, there are no internal methods that could be protected by simply signing a class. In addition, all methods can be changed at runtime, so must be protected at runtime.
In JavaScript you can add new properties to existing objects, or replace existing properties (including methods) at runtime. You cannot do this in Java. So, once again, protection that is automatic in Java must be handled separately in JavaScript.'
in the article at
http://docs.sun.com/source/816-6409-10/sec.htm
However, I would imagine that using private variables and methods might have some functionality in terms of resolving methods and variables that have the same signature but are in different classes, or not?
This question is similar to Why are methods in Ruby documentation preceded by a hash sign?
I understand why in Ruby instance methods are proceeded with a pound sign, helping to differentiate talking about SomeClass#someMethod from SomeObject.someMethod and allowing rdoc to work. And I understand that the authors of PrototypeJS admire Ruby (with good reason) and so they use the hash mark convention in their documentation.
My question is: is this a standard practice amongst JavaScript developers or is it just Prototype developers who do this?
Asked another way, is it proper for me to refer to instance methods in comments/documentation as SomeClass#someMethod? Or should my documentation refer to ``SomeClass.someMethod`?
No, I have not yet met another JavaScript project that uses this notation.
Something like this is useful in JavaScript, though, because unlike in many languages Class.methodName would refer to classmethods like String.fromCharCode, not instance methods which is what you are more often talking about. The method invoked by myinstance.methodName would be not MyClass.methodName but MyClass.prototype.methodName, and MyClass.prototype is an annoyance to keep typing.
(The standard JS library confuses this by making many instance methods also have a corresponding classmethod. But they're different functions.)
is it proepr for me to refer to instance methods in comments/documentation as SomeClass#someMethod?
Do what you like/find most readable. There's no standard here.
I think it comes from javadoc.
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html#{#link}