Skip to main content
Jump to: navigation, search

VJET/Validation Requirements

Contents

JSDT parse – produces syntax errors lists

Translation errors – errors are not reported to user

Resolution errors – errors are reported to user

Semantic validation errors

Syntax validation

Syntax version based on JavaScript 1.6.

We are using the JSDT syntax validation (deals with validation and error recovery)

We need to file bugs to them to fix problem areas.

TODO - Need to double check syntax version

Translation Errors – currently uses ErrorObject – move to IJstProblem

Semantic Validation Asserts

UniquenessValidator (IJstType and IJstTypeSpace required)

Local

assertUniqueMembers

vjo.ctype("a.b.c")

.protos({

a:1,

a:function(){}

})

.props({

b:1,

b:function(){}

})

assertUniqueParamsAndVariables

a:function(a,a){

var a; a;

}

Redefining variable is wrong
Redefining parameter is wrong
assertUniqueNeedNames

Global

assertUniqueType

vjo.type('a.b.c.A')

.endType();

vjo.type('a.b.c.A')

.endType();

Redefining the type can cause issues
assertNoNativeOverRides

vjo.type('Date')

.endType();


Redefining the native types can cause collisions
assertNoDomOverRides

vjo.type('window')

.endType();


Redefining the dom types can cause collisions

ResolutionValidation (Resolved Jst required)

If Build path is incorrect resolving will fail

assertResolvedNeeds
assertResolvedParamTypes
assertResolvedVarTypes
assertResolvedMethodTypes
assertResolvedPropertyTypes

DependencyValidation (Type + TS)

Local

assertNoUnusedNeeds
this can be problematic if developers use with or eval.
assertValidateUseNeedsAlias

vjo.ctype('partials.NeedsAliasTest')

.needs('partials.Bug2149TypeB', 'MyAlias');

.props({

main: function() { //< public void main (String ... arguments)

this.vj$.Myalias

}

}).endType();


this.vj$.Myalias – is wrong name

AccessValidation (Type + TS)

assertTypeRefCanAccessTargetType

assertMethodRefCanAccessTargetMethod

assertPropertyRefCanAccessTargetProperty

ModifierValidation

assertValidTypeModifiers

vjo.ctype('a.b.c.D') //<public final
public is ok
final is not okay we have vjo method for that

assertValidMethodModifiers

assertValidPropertyModifiers

assertValidVariableModifiers

VJOStructureValidation

RequiredInput

assertTypeHasStringInput
assertValidNeedsInput
assertProtosHasObjectLiteral
assertPropsHasObjectLiteral
assertInitsHasFunction

RequiredStructure

assertEndTypeAtEndOfTypeDef

vjo.type("vjo.example.ExVjoType")

.satisfies("vjo.example.ISatisfier")

.protos({

doIt:function(){

// impl goes here

},

doIt2:function(){

// impl goes here

}});


.endType() is missing after definition of protos
assertETypeRequiredKeywordSet
assertCTypeRequiredKeywordSet

vjo.ctype("a.b.c.D")

.expects()

.endType();

Expects is working
assertMTypeRequiredKeywordSet

BestCodePractices Asserts

These could be Find Bug style but are optional

Headless Requirement

Validation should work without Eclipse UI. Ensuring that all logic is in infrastructure to be used in other other tooling such as CLI or other tooling platform such as Netbeans.

Eclipse Integration

Validation Configuration

Validation Preferences

Enabling/Disabling Validation

Build automatically turns it on but we need way to filter and turn off JS errors.

Manual Validation

Hook into right click validate menu

Incremental validation

While you type for specific scope

Dependency validation

Using build spec in .project file

Validation filters

Because there are cases where you want to inherit old code you want ways to turn off validation.

3rd party code such as Js from Omniture
Other library code you do not own.

Validation markers

Ability to default problems to error, warning, informational as required.

Extension points for additional custom validation.

Misc

Nested types, all flavors and access control.


Do we support doing an anonymous inner class. This could be done with any ctype, ctype //< abstract or itype.


Completions, Proposals, Validations

There are relationships between these elements. First, lets describe each first.


Examples


if …

what follows must be a left paren.


SomeType. …

what follows are the various static properties and methods.


someInstance. …

what follows are the various instance properties and methods


if (someBoolExpr) { }…

what follows could be an else or some naked-target


somePkg. …

What follows are any types at the somePkg level as well as an subPackages


    1. Scope

These are the varying nested levels in which completions, proposals and validations occur. The scopes themselves are basically a tree, with each branch potentially being represented by a stack. At certain levels, not all branches may be needed or present at a give time.


For example we start with something like this…


Global (native JS types)

VjO Bootstrap

VjO Libs

AJAX

Others

HTML DOM Types

Specific Browser Types


    1. Context

What is the user trying to achieve? Are they typing where a package name is expected, a type, an instance method, a Boolean expr for a conditional etc…

    1. Naked Target

This is the term to describe what is possible in open whitespace where nothing else has been typed yet. For example if we are in the middle of a completed main(…) method, what proposals do you suggest at the …?


main: function(args) {

}


    1. Completions

A completion is:

  • an interactive authoring aid
  • the current type being authored may not be syntactically or semantically complete
  • may provide a fragment, skeleton, to complete expression/statement
  • can take into account other semantics such as VjO type structure
    1. Proposals

A proposal is:

  • an interactive authoring aid
  • the current type being authored may not be syntactically or semantically complete
  • describes everything that is known at a given scope/context in a source unit
  • uses information from the type space
  • uses information that can come from syntax options
  • normally active at the “dot” in expressions/statements
    1. Validations
  • Can take place at authoring time
  • Can take place on completed source units
  • Needs all the same information that completions and proposals do
  • Need to related back to specific line/col numbers for errors
  • Detailed messages are essential since errors may be in code that is not familiar to developer (i.e. their change broke code in someone else’s area)

General approach and guidelines

Semantic analysis should pay attention to functionally correct results first and then think of optimizations. This is not to say don’t think about optimizations, it’s just that we have such a limited time to pull this off.


The core data structures are graphs:

  • syntax AST
  • type space (graph with API’s)

Issues

We haven’t really addressed the cases where JavaScript semantics would be trumped by VjO type semantics. This might occur with Arrays, Strings and various implicit type conversions such as the + operator and Strings or such.

Environment Specifics

Part of the overall validation should take into account:

  • Version of JavaScript
  • Specific Browser/OS Version combination

Contexts and Scopes

I think we need to better define all the terms we are using to do Semantic Analysis.


Scopes are the levels at which specific elements are defined and/or made available.


Scopes

All of the available information we need

    1. Global (native JS Types)

VjO Bootstrap (vjo, vjo.Class, vjo.Object, vjo.Enum)


AJAX (service engine)


HTML DOM Types (classic DOM)


Specific Browser Types (per browser type)


Package


Type

under package space if we assume “default” name for a package. In actuality, we can just assume top level packages and top level types are at the same space.

Class

Static


Instance


Initializer


Interface

Static


Instance


Initializaer


Enum

Static


Instance


Initializer


Mixin

Static


Instance


OType

Defs


    1. Member

leftSide : rightHandExpr

    1. Method

name: function([args]) [throws A [ ,B ,C…]]


While within a method args trump

Constructor

specific checks with super


    1. Statement

Statements provide a scope where only certain other elements can occur. Much of the statements structure should come from syntactical checks.

    1. Expression

Relationship to TypeSpace and VJET

The validator will live outside of the TS.

The validator will leverage information from the TS.

VJET will use the validator to identify semantic warnings/errors etc… that should be reported to tool.

Validation should also work in batch or build mode where errors would be reported to a log or console. Similar to what javac would do.


Contexts

are the combination of activity and scope something is being validated.


Parsing

Syntax

We need to completely define “what” is catchable in our language grammar that is syntax oriented. For example, are we making sure that you can only use the keyword break in a loop or case statement. We need to know these so that we can determine what part of our processing: syntax, grammar or semantic are where we need to defines constraints and rules.


Keywords

You should avoid using these reserved words and keywords as function or variable names as JavaScript has reserved these words for its own use.


JavaScript Reserved Words
break continue do for import new this void
case default else function in return typeof while
comment delete export if label switch var with

All keywords must not be allowed to be used in:

  • package names
  • type names (any)
  • member names
  • method names
  • formal argument names
  • variable names
  • loop variables


Java Keywords (Reserved by JavaScript)
abstract implements protected
boolean instanceOf public
byte int short
char interface static
double long synchronized
false native throws
final null transient
float package true
goto private  
ECMAScipt Reserved Words
catch enum throw
class extends try
const finally  
debugger super  
Other JavaScript Keywords
alert eval Link outerHeight scrollTo
Anchor FileUpload location outerWidth Select
Area find Location Packages self
arguments focus locationbar pageXoffset setInterval
Array Form Math pageYoffset setTimeout
assign Frame menubar parent status
blur frames MimeType parseFloat statusbar
Boolean Function moveBy parseInt stop
Button getClass moveTo Password String
callee Hidden name personalbar Submit
caller history NaN Plugin sun
captureEvents History navigate print taint
Checkbox home navigator prompt Text
clearInterval Image Navigator prototype Textarea
clearTimeout Infinity netscape Radio toolbar
close innerHeight Number ref top
closed innerWidth Object RegExp toString
confirm isFinite onBlur releaseEvents unescape
constructor isNan onError Reset untaint
Date java onFocus resizeBy unwatch
defaultStatus JavaArray onLoad resizeTo valueOf
document JavaClass onUnload routeEvent watch
Document JavaObject open scroll window
Element JavaPackage opener scrollbars Window
escape length Option scrollBy  

Some of the most common/meaningful errors to catch

    1. Unknown references

In JavaScript the most common errors are related to making a reference to an object or property of an object that does not exist.


This check is at the root of many other checks as well (such as visibility and access control).

    1. Dependency

Based on some dependency mechanism – usually at a project level (ie above the normal Java package/access control levels) means you can’t “see” a specific type.

    1. Access Control

Access control is based on how an elements access is defined and who can see it based on a given access context. This is different from Dependency which says independent of access control whether you have the right to see a type at all.


    1. Methods

Wrong number or arguments


Should or should not return a value


Not returning the correct type


Packages

All of the various VjO types can have a package component to their names. Here are some rules with packages:

  • Each subpackage name must not collide with a global set of keywords
  • Each subpackage levels namespace must be unique between other subpackage names at that level as well as any other VjO types at that level

VjO Sections

All of the VjO types are composed of sections. These sections describe the specific type being created, various declarations and then a required ending section (.endType()). A section is really a method that takes an Object Literal as an argument.


Key
Note
Green Required. Each type starts with a section that says what kind of type we are defining.
Yellow Optional. Your type may or may not have this section depending on your needs.
Red Disallowed. This section is not valid for the specific type in question
0 .. n You can have 0 or more of these sections. A single section can contain multiple definitions for convenience.
0 .. 1 You can have 0 or 1 of these sections.
1 You must have only one of these sections.

When looking at the following table, find the type (class, interface, enum, etc…) you are interested in defining. The column for that type describes the sections that are valid for that type. The order of the rows (from top to bottom) for that column, is the order you should follow in your types definition.


sections
class/
abstract class
interface
enum
mixin
otype
vjo-type
.ctype
.itype
.etype
.mtype
.otype
.defs
X
X
X
X
1
.values
X
X
1
X
X
.options
0 .. 1
X
X
X
X
.needs
0 .. n
0 .. n
0 .. n
0 .. n
X
.needsLib
0 .. n
0 .. n
0 .. n
0 .. n
X
.inherits
0 .. 1
0 .. n
X
X
X
.satisfies
0 .. n
X
0 .. n
0 .. n
X
.requires
X
X
X
0 .. n
X
.expects
X
.mixin
0 .. n
0 .. n
0 .. n
X
X
.mixinProps
0 .. n
0 .. n
0 .. n
X
X
.props
0 .. 1
0 .. 1
0 .. 1
0 .. 1
X
.protos
0 .. 1
0 .. 1
0 .. 1
0 .. 1
X
.inits
0 .. 1
0 .. 1
0 .. 1
X
X
.endType
1
1
1
1
1

Access Control and Modifiers

Access control is based on how an elements access is defined and who can see it based on a given access context. This is different from Dependency which says independent of access control whether you have the right to see a type at all.


All access control and modifiers are defined using the structured VjO comment syntax. Applying these access controls and modifiers are leveraged by the VjO build process and VJET.

    1. public
    1. default
    1. protected
    1. private
    1. friend
    1. Access Table


public protected <default> private abstract final transient

Not supported yet

ctype
Yes
No
Yes
No
Yes
Yes
No
etype
Yes
No
Yes
No
Yes?
Yes?
No
itype
Yes
No
Yes
No
No
Yes?
No
otype
Yes
No
Yes
No
No
No
No
mtype
Yes
No
Yes
No
No
No
No
member
Yes
Yes
Yes
Yes
No
Yes
Yes
method
Yes
Yes
Yes
Yes
Yes
Yes
No
constructor
Yes
Yes
Yes
Yes
No
No
No
return type
No
No
No
No
No
No
No
argument
No
No
No
No
No
Yes
No
local variable
No
No
No
No
No
No
No
for loop variable
No
No
No
No
No
No
No
for in variable
No
No
No
No
No
No
No

Who is “this”

Who does “this” refer to while in the various VjO definition sections? The


sections
Who does “this” refer to
vjo-type Not applicable
.options Not applicable
.needs Not applicable
.needsLib Not applicable
.inherits Not applicable
.satisfies Not applicable
.requires Not applicable
.expects Not applicable
.mixin Not applicable
.mixinProps Not applicable
.props The type being defined (props – statics members)
.inits The type being defined (props – statics members)
.protos The instance (prototype – instance members)
.endType Not applicable

Sections

Ideally we can use tables to define these validations.


    1. order of sections
    1. certain sections only make sense for certain type
    1. how many of each section can occur
    1. arguments for each section
    1. Each Section

ctype


otype


mtype


itype


etype


options


defs


values


needs


.needs('Proc')

.needs('util.Proc')


.needs(['Proc'])

.needs(['util.Proc'])


.needs(['util.Proc', 'util.Proc2', 'Proc3'])


What is the reason we use an array? This may seem easier for our implementations but not necessarily easier for someone using it.


Having something like a comma-delimited single-string-literal seems easier to type and read.


.needs('util.Proc, util.Proc2, Proc3')


needsLib


inherits


satisfies


requires


expects


mixin


mixinProps


props


protos


inits


endType


Namespace

proper names such as a.b.c.Type

uniqueness – can’t have package a.b.C and a type a.b.C

types must be unique at each package level


Modifiers

    1. abstract

Only ctypes can be abstract

Only instance methods can be defined abstract and only in an abstract ctype

    1. final

ctypes but not abstract ctypes

methods

not constructors

members

arguments

    1. transient (not in use yet)

Error Messages

Misc

Arrays

Object Literals

Type References

Function References

Operators

    1. special

arguments

This is the built in variable for all function invocations.


doit: function(a, b) { //< void doit(int, boolean) {

var avalue = arguments[0] ; //< int

var bvalue = arguments[1] ; //<

}


new


objectName = new objectType(param1 [,param2] ...[,paramN])

Parameters

objectName 

Name of the new object instance.

objectType 

Object type. It must be a function that defines an object type.

param1...paramN 

Property values for the object. These properties are parameters defined for the objectType function.


instanceof


typeof


forms:

  • typeof operand
  • typeof (operand)

operand can really be any value or reference


This table summarizes the possible return values of typeof:


Type Result
Undefined "undefined"
Null "object"
Boolean "boolean"
Number "number"
String "string"
Host object (provided by the JS environment) Implementation-dependent
Function object (implements [[Call]] in ECMA-262 terms) "function"
Any other object "object"

delete

righthand has to be property or function.


We have issues is whether or not delete should even be allowed on VjO types since those types are based on full typespace consistency.


Dynamic objects created outside of VjO typespace should be ok.


We don’t have the notion of sealed types or sealed objects yet.

    1. Arithmetic

+


-


*


/


%


++


--


    1. Assignment

=


+=


-=


*=


/=


%=


    1. Comparison

==


!=


>


<


>=


<=


    1. Logical

&&


||


!


    1. Conditional (?:)

Statements

    1. if-else
    1. switch
    1. for loop
    1. while loop
    1. break loops
    1. for … in

for (variable in obj) { … }


The variable name becomes a new scoped name.

    1. try … catch
    1. throw
    1. onerror
    1. with

This is a tricky one as it creates a new scope for target object in the with(…)


function foo(){

with(document.forms[0]) {

var x = elements[0].value;

var y = elements[1].value;

with(elements[2]) {
var z = options[selectedIndex].text

}

}

}


To be figured out

JavaScript has built in values such as NaN, null and undefined that need to be thought out in terms of how they fit with our overall typing scheme.


For example an if or while etc… is based on a Boolean expression. However an if (somethingThatIsUndefined) is a common check in JavaScript.


Type Check

No.
Rule Description
Applicable Jst Node Types
Code Suggestion
Status/ONOFF
1 validity of assignment; rhs value is assignable to lhs value; AssignExpr TypeCheckUtil#isAssignable DONE/ON
2 type is allowed for the operations; PostfixExpr, PrefixExpr, InfixExpr TypeCheckUtil#isAssignable DONE/ON
3 array accessing index must be string/int ArrayAccessExpr DONE/ON
5 items' type are compatible with array def ArrayCreationExpr, JstArrayInitializer, ArrayLiteral   DONE/ON
6 id is array type ArrayCreationExpr  Yet DONE/OFF
8 cast to is assignable to cast from (Only used for Java2JS, skip this one) CastExpr revised DONE/OFF
9 then and else are compatible type ConditionalExpr   DONE/OFF
10 argument type satifies the parameter definition of the JstMethod (overloading method included) MtdInvocationExpr, ObjCreationExpr   DONE/ON
11 generics, JstTypeWithArgs satisfies JstType#getParamTypes boundaries MtdInvocationExpr, FieldAccessExpr   DONE/ON
12 exception type in CatchStmt is defined in the functions used in the block (Need to revisit this one later, can turn it off or skip it) TryStmt revised Yet DONE/OFF
13 switch expr type matches expr type in CaseStmt (Need to revisit this one later, can turn it off or skip it) SwitchStmt revised Done/OFF
14 expr type matches function return type RtnStmt   Done/ON

Hierachy/Structure

No.
Rule Description
Applicable Jst Node Types
Code Suggestion
Status
1 Override method should have wider visibility JstMethod DONE/ON
2 Override method should not have ambiguous signature JstMethod   DONE/ON
4 Mixin method should not conflict JstMethod   DONE/ON
5 Mixin property should not conflict JstProperty   DONE/ON
6 Methods defined in interface must be implemented in concrete type (ctype/etype) JstType revised DONE/ON
7 Abstract methods in super type must be implemented in concrete class JstType revised DONE/ON
8 case cannot fall thru (nice to have) JstSwitchStmt revised Yet DONE/OFF
9 override method cannot be called in constuctor (revisit this later, skip for now) JstConstructor revised Yet DONE/OFF
  property/method cannot be both abstract and final JstProperty, JstMethod    
10 return should present in function with a return type JstFunction   DONE/ON
11 statement should be reachable JstStatement   DONE/ON
  super type must be ctype for ctype, itype for itype JstType new DONE/ON
  satifies type must be an interface JstType new DONE/ON
  mixin type must be mtype JstType new DONE/ON
12 mtype cannot have constructor JstType new DONE/ON
  etype cannot be inherited JstType new DONE/ON
  otype cannot have none objLiteral property or none-abstract method JstType new  DONE/ON
  otype cannot be nested as inner type or outer type JstType new DONE/ON

Uniqueness

No.
Rule Description
Applicable Jst Node Types
Code Suggestion
Status
1 local variable id should be unique within its scope JstBlock For JstVar & JstVars statements, we need to look up the symbol table for existing variables|functions of the same id, jstMethod need to add its parameters to the symbol tables as well DONE/ON
2 name should be unique ObjLiteral DONE/ON
3 variable name conflict with reserved names in the scope, check Mr.P's document JstBlock, JstType revised DONE/ON
4 Needs should not have ambiguous ref JstType .needs("a.b.c.D", ) is empty alias treated differently DONE/ON
5 Method name should be unique JstType   DONE/ON
6 Property name should be unique JstType   DONE/ON
7 With scope's Property/Method name should not conflict with any local variables in the current scope (Need to revisit this later, can skip for now) WithStmt revised DONE/ON
8 Redeclare any variable is NOT ok, even conflict with func parameters   same as no.1 DONE/ON
9 Func args should be unique   new DONE/ON
10 Global vars should be unique (Need to revisit this later)     Yet DONE/OFF

Accessibility (var, func, scope)

No.
Rule Description
Applicable Jst Node Types
Code Suggestion
Status
1 qualifier must be defined FieldAccessExpr, MtdInvocationExpr DONE/ON
2 qualifier type must be initialized FieldAccessExpr, MtdInvocationExpr, ObjCreationExpr,   DONE/ON
3 field/method must be defined/unless dynamic qualifier type presents FieldAccessExpr, MtdInvocationExp, ObjCreationExpr,   DONE/ON
4 field/method must be visible FieldAccessExpr, MtdInvocationExp, ObjCreationExp,  DONE/ON
5 static field/method cannot be accessed from instance scope FieldAccessExpr, MtdInvocationExp, ObjCreationExp,     DONE/ON
6 field/func is defined FieldAccessExpr, MtdInvocationExp, ObjCreationExp,   DONE/ON
7 none-static field/method cannot be accessed from static scope FieldAccessExpr, MtdInvocationExp, ObjCreationExp,   DONE/ON
8 Ref types must be in Type space JstType   DONE/ON
9 Ref types must have a needs or honory needs (inherience, implements, etc) JstVars, JstProperty, JstMethod com.ebay.dsf.jst.ts.util.JstTypeDependencyCollector DONE/ON

Misc

No.
Rule Description
Applicable Jst Node Types
Code Suggestion
Status
1 all final properties are initialized. JstInitializer for static prop Constructor for instance prop revised DONE/ON
2 final variable should be assigned only in def or init (Can be turn off for now, revisite later) JstType,  JstInitializer revised DONE/OFF

Vjo Syntax

No.
Rule Description
Applicable Jst Node Types
Code Suggestion
Status
1 All the method (TODO: list all methods) in "Vjo" type should called resonable times only except utils method. scope: global, JstBlock of Vjo Type Def Tree in IScriptUnit revised DONE/ON
2 The method call sequence need to be right. scope: global, JstBlock of Vjo Type Def Tree in IScriptUnit   DONE/ON
3 All the method (TODO: list all methods) in "xType" type should called resonable only except utils method. CType, EType, ... revised DONE/ON
4 The method call sequence need to be right for "xType". CType, EType, ...    DONE/ON

Coding Style (NOT in this release)

No.
Rule Description
Applicable Jst Node Types
Code Suggestion
1 unused local variables (warning) JstBlock  
2 empty block (warning) JstBlock  
3 function params should not be assigned (warning)  JstBlock  
4 assignment has no effect (x=x) AssignExpr  
5 possible accidental boolean assignment (if(a=b)) IfStatment  
6    

Back to the top