VJET/Validation Requirements

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;

}

Global

assertUniqueType

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

.endType();

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

.endType();

assertNoNativeOverRides

vjo.type('Date')

.endType();

assertNoDomOverRides

vjo.type('window')

.endType();

DependencyValidation (Type + TS)

Local

assertValidateUseNeedsAlias

vjo.ctype('partials.NeedsAliasTest')

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

.props({

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

this.vj$.Myalias

}

}).endType();

VJOStructureValidation

RequiredStructure

assertEndTypeAtEndOfTypeDef

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

.satisfies("vjo.example.ISatisfier")

.protos({

doIt:function(){

// impl goes here

},

doIt2:function(){

// impl goes here

}});

assertCTypeRequiredKeywordSet

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

.expects()

.endType();

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. 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. 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. 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. 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. 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. 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. 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. 1. Member

leftSide : rightHandExpr

1. 1. Method

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

While within a method args trump

Constructor

specific checks with super

1. 1. Statement

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

1. 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.

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. 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. 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. 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. 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. 1. public

1. 1. default

1. 1. protected

1. 1. private

1. 1. friend

1. 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. 1. order of sections

1. 1. certain sections only make sense for certain type

1. 1. how many of each section can occur

1. 1. arguments for each section

1. 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. 1. abstract

Only ctypes can be abstract

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

1. 1. final

ctypes but not abstract ctypes

methods

not constructors

members

arguments

1. 1. transient (not in use yet)

Operators

1. 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. 1. Arithmetic

+

-

*

/

%

++

--

1. 1. Assignment

=

+=

-=

*=

/=

%=

1. 1. Comparison

==

!=

>

<

>=

<=

1. 1. Logical

&&

||

!

1. 1. Conditional (?:)

Statements

1. 1. if-else

1. 1. switch

1. 1. for loop

1. 1. while loop

1. 1. break loops

1. 1. for … in

for (variable in obj) { … }

The variable name becomes a new scoped name.

1. 1. try … catch

1. 1. throw

1. 1. onerror

1. 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