Planned breaking JS changes in 0.19

TL;DR: Make sure your projects are compiled fine with `grunt`. You will
need to recompile them from source.

Hi,

as Amber uses different mangling techniques and internal fields for its
working, and is aimed to play nicely with the ecosystem, I thought for
long those should be changed so they are more "mangled" and create less
probability of nameclash; it is also a moment where they can be unified.

I think of changing those this way:

Meaning Old New
Class o.klass o.a$cls
Represents nil? o.isNil o.a$nil
ivar foo o["@foo"] o.a$iv$foo
ST: o size $recv(o)._size() $recv(o).a$se$size()
ST: o << 'Hi' $recv(o).__lt_lt("Hi") $recv(o)["a$se$<<"]("Hi")
ST: o value: 4 $recv(o)._value_(4) $recv(o).a$se$value$(4)
old JS fallback o.allowJavaScriptCalls o.a$fbk

(maybe I could remove allowJavaScriptCalls completely - it first tries
Smalltalk dispatch, then fallbacks to try JS - seems strange and is not
used anymore in favour of `Smalltalk optOut:` which marks ST object JS only)

Bottom line is, first five chars are always 'a$xyz', and fifth char is
'$' if the rest is meant as the payload. Thus, conversions are easier,
and the scheme hopefully leads to no nameclash with other libs.

The change in selector mangling also opens the way to allow underscores
in selectors.

Caveat is, old code will NOT LOAD. Everything (libs, app code) must be
recompiled, if not supplied with new version already (which Amber and
the accompanying libs would be, of course).

Thoughts? Objections?

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Dave Mason wrote:
> replacing a["@foo"] with a.foo or something provides a noticeable
> speedup on Safari. (Irrelevant for the rest).

Well, that wasn't the main motivation (and frankly as both do the same,
there should not be any performance penalty there).

> In PharoJS we code instance variables as simple name (a.foo), unary and

Amber mangles probably because of "wrapped" classes (Number, String,
Array, Error, Date, ...) of native JS where this could lead to nameclash
(Nico should know better why).

I believe that mangling should stay atm, too.

But subclassing JS classes inside Amber (`extends React.Component`) is
hard and I still don't know how to tackle it, in general. This is only
thing I can imagine that could persuade me not to mangle ivars (if that
would help) that I currently see.

> keyword selectors the same as Amber, and binary as ASCII code values -
> for example == is named _61_61_ (the reason is that virtually every
> character except .,^(){}[]$: are legal as part of binary operator (note,
> including \|= ) and we didn't want to miss one). If you're changing
> anyway, changing the handling of instance variables would make code more
> portable between us.  In particular, it allows accessing fields of
> PharoJS objects more natural in JS.

Not seeing what led to this conclusion. I am planning to use different
magling scheme, not abandon mangling.

These two ^^^ are already in 0.19, other aren't in yet.

>     ivar foo        o["@foo"]               o.a$iv$foo
>     ST: o size      $recv(o)._size()        $recv(o).a$se$size()
>     ST: o << 'Hi'   $recv(o).__lt_lt("Hi")  $recv(o)["a$se$<<"]("Hi")
>     ST: o value: 4  $recv(o)._value_(4)     $recv(o).a$se$value$(4)
>     old JS fallback o.allowJavaScriptCalls  o.a$fbk
>
>     (maybe I could remove allowJavaScriptCalls completely - it first

I did.

>     tries Smalltalk dispatch, then fallbacks to try JS - seems strange
>     and is not used anymore in favour of `Smalltalk optOut:` which marks
>     ST object JS only)
>
>     Bottom line is, first five chars are always 'a$xyz', and fifth char

This would be incompatible with PharoJS, wouldn't it?

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.