Re: [Vexi-core] Vexi 4 - proposed syntax and improvements

[Mike G. <mik...@ca...>]

*9) *Move svn repository to our servers. They are run on a slightly longer
shoestring than sourceforges...

*10)* Prototypes in markup.

<path.to.Singleton/>
<ui:Box>
   // our object, with path.to.Singleton as a prototype
</ui:Box>

Prototyping will be simpler than/differ from regular javascript.

   - Types may have multiple prototypes.
   - Prototypes are types (if an object inherits from one then it becomes
   one of the object's types)
   - If a property is not found on an object then the lookup is done on the
   prototypes (in order of most recently added)

Most things can be done with templates and do not need prototypes. However
prototypes do allow dynamically changing a whole class of objects with a
single assignment. This could be useful, for example in styling. The fill
property could be changed for an entire class of objects at once. (Dirtying
would have to be done manually by requesting a screen wide refresh when
doing this, as I do not think we would support messaging of all instances
of a prototype to do something about the updated value)

Prototypes can be potentially memory saving - it becomes possible to have
small objects with a lot of functionality.


*11)* Remove typeof keyword. It is pathetically inadequate. Everything
should use the 'is' keyword instead (replacing instanceof).

if(a is vexi.js.String){
   ...
}

*12)* 'Meta' properties using the @ operator. Javascript objects have
namespace issues. Really they need a second namespace for all the special
stuff. Currently we have keysof keyword and most special properties are
handled through that. I would expect to have these kind of meta properties

ob...@ke...move("x")
ob...@ke...ray               (returns an array of keys)
obj@prototypes               (list of all prototypes)
obj@constructors            (list of all constructors - i.e. applied
templates+system constructors)
obj@types                      (list of all constructors+prototypes)


*13)* Library improvements. This is just going to be a lot of judgement.
Certain System actions need to be contained in the library, e.g. opening
files. Other perhaps utility code requires a judgement on whether it should
be there. The current organisation could doubtless be improved.

*13b)* Move to use new date/time types. Remove old js ecma date object, it
is not good. Correctness (or rather ease of correctness) is too important
to worry about messing around with old standards. Essentially old computing
approaches
have in attempting to merge functionality created a lot of problems. Date
and time are just two different, albeit related concepts.

The two fundamentals types are
   vexi.js.Instant
   vexi.js.Date

Instant is essentially the UTC in millis (or even better UTC equivalent
without leap seconds)

Date is just the gregorian date, without any time element. Converting
between times and dates requires specifying, not assuming any extra
information (i.e. timezones, time of day). Using a different calendar would
require using a different type. It should make no effort to support other
calendars as this is a mistake.


*14)* String concatenation operator '~'.  I think the current '+'
overloading is essentially unnecessary and a source of errors (and a degree
of inefficiency).


- mike