Skip to end of metadata
Go to start of metadata

In statically typed scenarios (closure world etc) - we can do automatic refactoring like java - where the language knows the name resolution, outer classes are closed (not dynamic etc). Let's notice not all refactorings can be done automatically

Closure world...

  • Name resolution rules...
  • local variable name
  • (all variables declared in closures are considered local vars)
  • outer class static names
  • outer class dynamic names
  • Code can move into and out of closures WITHOUT any changes - irrespective of the method implemetnation detail
  • the compiler, IDE, shell can KNOW that the names map to (assuming the outer class is static, not open/dymamic

Builder world

  • The builder decides what vanilla names mean

normal static resolution

  • local variables
  • delegate to builder.. it decides...
  • default order is,
  • static builder names
  • static outer class names
  • dynamic builder names
  • dynamic outer class names
  • Builders

possible precedence rules from within usage of a builder

Johns proposal...

  • local variables
  • static outer class names
  • dynamic outer class names
  • static builder names
  • dynamic builder names

James proposal...

normal static resolution

  • local variables
  • static outer class names

changed dynamic resolution...

  • static builder names
  • dynamic builder names
  • dynamic outer class names

Markup ideas

Stuff Guillaume is happy-enough with

Other ideas

Passing closures into markup

Guillaumes suggestion....

  • markup

(* regular method call

Random bits of snippets

In scripts, what should be in the binding? or local variables?

Jochen:

  • is it dependent on type of value or type of variable
  • discussion ensued about static compile time checing
  • if Foo has a method added after compiletime such as getBar(),
    then should the compiler give error... (as above in Foo)?
  • vanilla names used to catch typos, whereas in markup the typos are ignored?
  • late binding on properties and methods, but not on names
  • good error handling is important
  • lexical scope has to be handled by compiler
  • classnames can't be dynamically bound
  • scripts are normally associated with command line shells, and you have the concept of a variable stack.
  • threadlocal variable scope?
  • maybe when extending Expando, vanilla names are unbound?
  • Not a lexical name, e.g. $foo is like a dynamic name which no
    checking is done for.
  • $ seems slightly cleaner, because it is like a seperate namespace
  • println foo.?bar
  • An explicit syntax to mean a dynamic name
  • 3 Options
    or
    or

scope:

or

or

  • there needs to be an explicit rule where names are searched

Choice:

Either...

  • Vanilla Name Resolution uses the names in the current editor
    (bound to the lexical context)

or

  • Vanilla Name Resolution uses the names in the enclosing object
    (bound to the instance being referenced at the time)

or

both! - which is default, what is syntax for non-default
e.g.

jstrachan - "foo should be looked for in the metaclass of the outer class,
it should never look in the metaclass of the closure"

  • No labels