Re: constructor, super, and data members issue

2018-08-25 Thread Aaron Gray
On Sat, 25 Aug 2018 at 00:35, Logan Smyth  wrote:

> Generally if something is required during construction, it would be best
> to pass it down as part of the constructor options. For example, you could
> do
> ```
> class Base {
>   constructor({ idAttribute = "id"}) {
> this.idAttribute = idAttribute;
>   }
> }
>
> class Derived extends Base {
>   constructor() {
> super({
>   idAttribute: '_id'
> });
>   }
> }
> ```
>

I had derived a simular solution.


> I don't think class fields would be a good way to conceptually do this
> kind of thing.
>

It was neat for what I wanted to do.

>
>
> On Fri, Aug 24, 2018 at 2:56 PM, Aaron Gray 
> wrote:
>
>> Yeah it does look like its badly "broken by design".
>>
>> On Fri, 24 Aug 2018 at 22:13, Jordan Harband  wrote:
>>
>>> I'm afraid that still wouldn't solve the problem; the superclass's code
>>> is all 100% completed before the subclass has `this` available.
>>>
>>> On Fri, Aug 24, 2018 at 1:52 PM, Ranando King  wrote:
>>>
>>>> Aaron, congratulations! You just tripped over a new reason for me to
>>>> revive issue #123. The only way to get that to work is to have the default
>>>> values on the prototype. The problem comes because `this` doesn't even have
>>>> a value until the last call to `super()` returns. If a `class` doesn't have
>>>> a base `class` it essentially has Object as a base `class` and `super` is
>>>> implicitly called. So unless the default public field values are on the
>>>> prototype, there's literally no way to have them initialized before the
>>>> base classes are initialized.
>>>>
>>>> On Fri, Aug 24, 2018 at 3:15 PM Aaron Gray 
>>>> wrote:
>>>>
>>>>> I am having an issue with order semantics regarding
>>>>> https://github.com/tc39/proposal-class-fields with derived classes
>>>>> defining or overriding data member values that are used in the base class
>>>>> constructor for initialization of properties of the class.
>>>>>
>>>>> This means the Super Class / Base Class'es constructor does not yet
>>>>> have access to the default field values of the derived class it is
>>>>> initiating.
>>>>>
>>>>> class Base {
>>>>> constructor() {
>>>>>  
>>>>>  .. idAttribute ..
>>>>>  
>>>>> }
>>>>> idAttribute = 'id';
>>>>> }
>>>>>    class Derived extends Base {
>>>>> constructor() {
>>>>>  super();
>>>>>  
>>>>> }
>>>>> idAttribute = '_id';
>>>>>}
>>>>>
>>>>> All would mean having a separate initialize() function, but even this
>>>>> solution is flawed when there is a third level in the hierarchy. And as
>>>>> super() is required it means there seems to be no way round this issue. 
>>>>> The
>>>>> only way I can see is some form of override keyword ?
>>>>>
>>>>>
>>>>> Has anyone got any solutions to this issue or work arounds ?
>>>>> --
>>>>> Aaron Gray
>>>>>
>>>>> Independent Open Source Software Engineer, Computer Language
>>>>> Researcher, Information Theorist, and amateur computer scientist.
>>>>> ___
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>
>> --
>> Aaron Gray
>>
>> Independent Open Source Software Engineer, Computer Language Researcher,
>> Information Theorist, and amateur computer scientist.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: constructor, super, and data members issue

2018-08-24 Thread Aaron Gray
Yeah it does look like its badly "broken by design".

On Fri, 24 Aug 2018 at 22:13, Jordan Harband  wrote:

> I'm afraid that still wouldn't solve the problem; the superclass's code is
> all 100% completed before the subclass has `this` available.
>
> On Fri, Aug 24, 2018 at 1:52 PM, Ranando King  wrote:
>
>> Aaron, congratulations! You just tripped over a new reason for me to
>> revive issue #123. The only way to get that to work is to have the default
>> values on the prototype. The problem comes because `this` doesn't even have
>> a value until the last call to `super()` returns. If a `class` doesn't have
>> a base `class` it essentially has Object as a base `class` and `super` is
>> implicitly called. So unless the default public field values are on the
>> prototype, there's literally no way to have them initialized before the
>> base classes are initialized.
>>
>> On Fri, Aug 24, 2018 at 3:15 PM Aaron Gray 
>> wrote:
>>
>>> I am having an issue with order semantics regarding
>>> https://github.com/tc39/proposal-class-fields with derived classes
>>> defining or overriding data member values that are used in the base class
>>> constructor for initialization of properties of the class.
>>>
>>> This means the Super Class / Base Class'es constructor does not yet have
>>> access to the default field values of the derived class it is initiating.
>>>
>>> class Base {
>>> constructor() {
>>>  
>>>  .. idAttribute ..
>>>  
>>> }
>>> idAttribute = 'id';
>>> }
>>>class Derived extends Base {
>>> constructor() {
>>>  super();
>>>  
>>> }
>>> idAttribute = '_id';
>>>}
>>>
>>> All would mean having a separate initialize() function, but even this
>>> solution is flawed when there is a third level in the hierarchy. And as
>>> super() is required it means there seems to be no way round this issue. The
>>> only way I can see is some form of override keyword ?
>>>
>>>
>>> Has anyone got any solutions to this issue or work arounds ?
>>> --
>>> Aaron Gray
>>>
>>> Independent Open Source Software Engineer, Computer Language Researcher,
>>> Information Theorist, and amateur computer scientist.
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: __line_number__ and __filename__

2018-08-24 Thread Aaron Gray
Its not rocket science :)

On Fri, 24 Aug 2018 at 21:59, Ranando King  wrote:

> Realistically, the engine would give back file name and line number (and
> hopefully character offset) of the code from the fully translated, fully
> minified, actual logic that the engine loaded. Source maps could be used to
> convert that obscure value back into actual original source code locations.
> It would also be nice if there were a way to perform a lookup at runtime, a
> function that takes a function and returns the internal Location object for
> that function.
>
> On Fri, Aug 24, 2018 at 3:16 PM Aaron Gray 
> wrote:
>
>> Ideally at some point we won't be using transpilers anymore ;)
>>
>>
>> On Fri, 24 Aug 2018 at 19:37, Bob Myers  wrote:
>>
>>> What does line number, or filename for that matter, mean when a file has
>>> gone through one or more transpilation and/or minification passes?
>>> Is the notion that the first processor that touches the file would
>>> substitute those values?
>>>
>>> Bob
>>>
>>>
>>> On Fri, Aug 24, 2018 at 11:34 PM Claude Pache 
>>> wrote:
>>>
>>>>
>>>>
>>>> Le 24 août 2018 à 05:55, J Decker  a écrit :
>>>>
>>>> On Thu, Aug 23, 2018 at 5:26 PM Aaron Gray 
>>>> wrote:
>>>>
>>>>> I am debugging existing code that I have modularized, and am
>>>>> class'izing that has unittests and it just would have been very useful to
>>>>> have this facility.
>>>>>
>>>> In a  browser, console.log is usually associated with the file and line
>>>> number anyway; which includes using devtools with node but it would be
>>>> handy for logging.  with V8 there is console.trace; which spits out the
>>>> stack trace too... before I discovered that I did a logging function
>>>> like...
>>>>
>>>> (from
>>>> https://stackoverflow.com/questions/591857/how-can-i-get-a-javascript-stack-trace-when-i-throw-an-exception
>>>> )
>>>> function stackTrace() { var err = new Error(); return err.stack; }  //
>>>> parse stack to get frame-1 online
>>>>
>>>> // or maybe just frame-1...
>>>> function stackTrace() { var err = new Error(); return err.stack.split(
>>>> "\n" )[1]; }
>>>>
>>>> ---
>>>> function stacktrace() {
>>>>   function st2(f) {
>>>> return !f ? [] :
>>>> st2(f.caller).concat([f.toString().split('(')[0].substring(9) +
>>>> '(' + f.arguments.join(',') + ')']);
>>>>   }
>>>>   return st2(arguments.callee.caller);
>>>> }
>>>>
>>>>  EDIT 2 (2017) :
>>>>
>>>> In all modern browsers you can simply call: console.trace(); (MDN
>>>> Reference)
>>>> ---
>>>>
>>>> Although I do still miss just being able to get __FILE__ and __LINE__
>>>>
>>>>
>>>>
>>>> See also:
>>>>
>>>> https://github.com/tc39/proposal-error-stacks
>>>>
>>>> If/when that proposal is implemented, you'll have a simple way to get a
>>>> *structured* representation of the trace:
>>>>
>>>> ```js
>>>> System.getTrace(new Error)
>>>> ```
>>>>
>>>> from which you can much more easily extract line number, filename, etc.
>>>>
>>>> —Claude
>>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> --
>> Aaron Gray
>>
>> Independent Open Source Software Engineer, Computer Language Researcher,
>> Information Theorist, and amateur computer scientist.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: __line_number__ and __filename__

2018-08-24 Thread Aaron Gray
Ideally at some point we won't be using transpilers anymore ;)


On Fri, 24 Aug 2018 at 19:37, Bob Myers  wrote:

> What does line number, or filename for that matter, mean when a file has
> gone through one or more transpilation and/or minification passes?
> Is the notion that the first processor that touches the file would
> substitute those values?
>
> Bob
>
>
> On Fri, Aug 24, 2018 at 11:34 PM Claude Pache 
> wrote:
>
>>
>>
>> Le 24 août 2018 à 05:55, J Decker  a écrit :
>>
>> On Thu, Aug 23, 2018 at 5:26 PM Aaron Gray 
>> wrote:
>>
>>> I am debugging existing code that I have modularized, and am class'izing
>>> that has unittests and it just would have been very useful to have this
>>> facility.
>>>
>> In a  browser, console.log is usually associated with the file and line
>> number anyway; which includes using devtools with node but it would be
>> handy for logging.  with V8 there is console.trace; which spits out the
>> stack trace too... before I discovered that I did a logging function
>> like...
>>
>> (from
>> https://stackoverflow.com/questions/591857/how-can-i-get-a-javascript-stack-trace-when-i-throw-an-exception
>> )
>> function stackTrace() { var err = new Error(); return err.stack; }  //
>> parse stack to get frame-1 online
>>
>> // or maybe just frame-1...
>> function stackTrace() { var err = new Error(); return err.stack.split(
>> "\n" )[1]; }
>>
>> ---
>> function stacktrace() {
>>   function st2(f) {
>> return !f ? [] :
>> st2(f.caller).concat([f.toString().split('(')[0].substring(9) +
>> '(' + f.arguments.join(',') + ')']);
>>   }
>>   return st2(arguments.callee.caller);
>> }
>>
>>  EDIT 2 (2017) :
>>
>> In all modern browsers you can simply call: console.trace(); (MDN
>> Reference)
>> ---
>>
>> Although I do still miss just being able to get __FILE__ and __LINE__
>>
>>
>>
>> See also:
>>
>> https://github.com/tc39/proposal-error-stacks
>>
>> If/when that proposal is implemented, you'll have a simple way to get a
>> *structured* representation of the trace:
>>
>> ```js
>> System.getTrace(new Error)
>> ```
>>
>> from which you can much more easily extract line number, filename, etc.
>>
>> —Claude
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


constructor, super, and data members issue

2018-08-24 Thread Aaron Gray
I am having an issue with order semantics regarding
https://github.com/tc39/proposal-class-fields with derived classes defining
or overriding data member values that are used in the base class
constructor for initialization of properties of the class.

This means the Super Class / Base Class'es constructor does not yet have
access to the default field values of the derived class it is initiating.

class Base {
constructor() {
 
 .. idAttribute ..
 
}
idAttribute = 'id';
}
   class Derived extends Base {
constructor() {
 super();
 
}
idAttribute = '_id';
   }

All would mean having a separate initialize() function, but even this
solution is flawed when there is a third level in the hierarchy. And as
super() is required it means there seems to be no way round this issue. The
only way I can see is some form of override keyword ?


Has anyone got any solutions to this issue or work arounds ?
-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: __line_number__ and __filename__

2018-08-24 Thread Aaron Gray
On Fri, 24 Aug 2018 at 16:34, Peter Jaszkowiak  wrote:

> Did nobody see my email? There is already a mechanism in the works for
> exposing this kind of metadata:
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta
>
> https://github.com/tc39/proposal-import-meta/blob/master/README.md
>

Thanks, thats probably okay for the filename but for line number
information that does not realy look too applicable and ideally both have a
simular mechanism.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: __line_number__ and __filename__

2018-08-24 Thread Aaron Gray
On Fri, 24 Aug 2018 at 04:56, J Decker  wrote:

> On Thu, Aug 23, 2018 at 5:26 PM Aaron Gray 
> wrote:
>
>> I am debugging existing code that I have modularized, and am class'izing
>> that has unittests and it just would have been very useful to have this
>> facility.
>>
> In a  browser, console.log is usually associated with the file and line
> number anyway; which includes using devtools with node but it would be
> handy for logging.  with V8 there is console.trace; which spits out the
> stack trace too... before I discovered that I did a logging function
> like...
>
> (from
> https://stackoverflow.com/questions/591857/how-can-i-get-a-javascript-stack-trace-when-i-throw-an-exception
> )
> function stackTrace() { var err = new Error(); return err.stack; }  //
> parse stack to get frame-1 online
>
> // or maybe just frame-1...
> function stackTrace() { var err = new Error(); return err.stack.split(
> "\n" )[1]; }
>
> ---
> function stacktrace() {
>   function st2(f) {
> return !f ? [] :
> st2(f.caller).concat([f.toString().split('(')[0].substring(9) +
> '(' + f.arguments.join(',') + ')']);
>   }
>   return st2(arguments.callee.caller);
> }
>
>  EDIT 2 (2017) :
>
> In all modern browsers you can simply call: console.trace(); (MDN
> Reference)
>

Yes slightly long winded to say the least :)


> ---
>
> Although I do still miss just being able to get __FILE__ and __LINE__
>

Yeah it should be easy to have such stuff compiled by JIT

Aaron

> -Gus
>>>
>>>  On Thu, 23 Aug 2018 17:56:43 -0500 *Aaron Gray
>>> >* wrote 
>>>
>>> I wondering what people think about the idea of proposing being able to
>>> get the line number and filename of executing code in the code ? Maybe with
>>> something simular to C preprocessors __line_number__ and __filename__. Or
>>> as subobjects of global ?
>>>
>>> --
>>> Aaron Gray
>>>
>>> Independent Open Source Software Engineer, Computer Language Researcher,
>>> Information Theorist, and amateur computer scientist.
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>>>
>>
>> --
>> Aaron Gray
>>
>> Independent Open Source Software Engineer, Computer Language Researcher,
>> Information Theorist, and amateur computer scientist.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: __line_number__ and __filename__

2018-08-23 Thread Aaron Gray
I am debugging existing code that I have modularized, and am class'izing
that has unittests and it just would have been very useful to have this
facility.

On Fri, 24 Aug 2018 at 00:27, Gus Caplan  wrote:

> What is the reasoning behind wanting this data? For example, in
> exceptional cases you should be creating errors which already have stacks
> containing this information.
>
> -Gus
>
>  On Thu, 23 Aug 2018 17:56:43 -0500 *Aaron Gray
> >* wrote 
>
> I wondering what people think about the idea of proposing being able to
> get the line number and filename of executing code in the code ? Maybe with
> something simular to C preprocessors __line_number__ and __filename__. Or
> as subobjects of global ?
>
> --
> Aaron Gray
>
> Independent Open Source Software Engineer, Computer Language Researcher,
> Information Theorist, and amateur computer scientist.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


__line_number__ and __filename__

2018-08-23 Thread Aaron Gray
I wondering what people think about the idea of proposing being able to get
the line number and filename of executing code in the code ? Maybe with
something simular to C preprocessors __line_number__ and __filename__. Or
as subobjects of global ?

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Class data member declarations proposal idea

2018-08-10 Thread Aaron Gray
On Fri, 10 Aug 2018 at 00:09, Logan Smyth  wrote:

> It might help if you could clarify how your proposal diverges from the
> class fields proposal that you linked to. From purely a syntactic view,
> ignoring the type annotations, I don't see an obvious difference, so it is
> hard to tell what your expectations are. You state "I have shown the idea
> of declaring subobject default value declarations.", but I can't actually
> tell what that means or what you intended to show. Is
> ```
> defaults = {
>   a: 1,
>   b: 2
> }
> ```
> meant to create a property called `defaults`, or do something else?
>

That and the syntax.

Aaron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Class data member declarations proposal idea

2018-08-09 Thread Aaron Gray
On Wed, 8 Aug 2018 at 14:34, Ranando King  wrote:

> Did you see any similarity with my proposal-object-members
> ? It doesn't have type
> annotation either. However, that's probably something best left to a
> separate proposal since it would affect private and public members alike.
>

This looks excellent.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Class data member declarations proposal idea

2018-08-08 Thread Aaron Gray
On Tue, 7 Aug 2018 at 22:34, Waldemar Horwat  wrote:

> See this proposal, currently at stage 3:
> https://github.com/tc39/proposal-class-fields
>
>
Yes I did reference the proposal my mail.

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Class data member declarations proposal idea

2018-08-07 Thread Aaron Gray
Hi,

I am looking for help working on a TC39 proposal for declaring class data
members, their default values, and possibly annotated typing. The fact that
this is missing means there is little continuity between classes and
existing prototypical object declarations. I have been moving Backbone.js
and Underscore.js to modern class'ized JavaScript and have found that this
will be needed for moving existing JavaScript libraries forward.

abstracted syntax example :-

class X extends Y {
constructor() { ... }
defaults = {
a: 1,
b: 2
}
x : Integer = 3
aMethod() { ... }
}

syntax modifications :-

ClassElement [Yield, Await]:
MethodDefinition [?Yield, ?Await]
"static" MethodDefinition [?Yield, ?Await]
FieldDefinition
"static" FieldDefinition
;

FieldDefinition:
Identifier "=" PrimaryExpression

This is probably slightly oversimplified at this stage with the syntactic
rules, but this gives a preliminary idea of what is being proposed. This is
similar to the following proposal
https://github.com/tc39/proposal-class-fields but I have shown the idea of
declaring subobject default value declarations.

Type annotations would also be a good idea and allow at the least initial
type checking for the default values, but this would not fit with subobject
declarations and is a very complex area to take forward for any more level
of type checking, although Facebook's Flow and MicroSoft's TypeScript, and
a Babel plugin flow-runtime demonstrate that this is possible.
https://github.com/codemix/flow-runtime


-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Is there an ES5 Draft summary anywhere

2009-05-04 Thread Aaron Gray
Has anyone done a summary of changes in the ES5 draft for those who dont like 
reading specs ?

If no one has done this it would be a good idea to do.

Many thanks in advance,

Aaron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Allen's lambda syntax proposal

2008-12-02 Thread Aaron Gray

On Dec 2, 2008, at 5:31 AM, Aaron Gray wrote:

i still prefer 'lambda (a,b,c) { ... }' as it is readable to the 
uninitiated and can then at least give a handle for someone to lookup.




I think the truly uninitiated would not find lambda any more obvious  in 
meaning than \ or ||.


People can google lambda they cannot google \, or ||. Also keywords 
seem better suited to Javascript syntax.


Aaron

___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Newbie Q's

2008-12-01 Thread Aaron Gray

Aaron Gray wrote:

Hi,
 I have been beginning to read the ML reference implementation and have a 
few basic questions.

 What is REPL and what does it stand for ?
 What is a RIB and does it stand for anything ?
 What are FIXTURES ?


REPL stands for read, eval, print loop. It's lisp slang for interactive 
programming-language prompt.


Yes I found that one, cheers :)

A fixture (in ES4-ese) is a fixed property -- either of a scope, an 
object type, or a class -- known at definition-time. A rib (in ES4-ese) 
is a static map from names to fixtures. It's not an acronym.


Okay, I get that now. Strange terms.

This is all written up in the last draft of the ES4 proto-speclets. But at 
this point it doesn't matter.


Considering how much of the ES4 design is now either permanently off the 
table or in indefinitely deferred status awaiting re-appraisal in the 
future ES-harmony effort, I'd recommend *against* reading the existing ES4 
RI. It's more likely to confuse than to illuminate. Probably we should 
take the links to it down, at least for the time being.


Sorry to be the bearer of bad news.


No I should have joined the mailing list sooner than I did !

Its a great shame I was very looking forward to the pre harmony ES4.

I have been reading Tamarin source on and off for a couple of months or so, 
and had just started with the RI.


Luckily for me I am only really interested on an academic level and seeing 
how far static/dynamic language divide can be pushed.


Looks like order and attribution problems of text based scripting languages 
in general. Had ECMAScript progressed onto a binary bytecoded distribution 
format like ActionScript then maybe these problems could have been solved, 
but then I am forgetting ES3.1.


Order dependance is a difficult one.

Many thanks for the reply,

Aaron

___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Understanding reasons for Harmony

2008-12-01 Thread Aaron Gray
Brendan,

Great shame, but as you say its a broken design.

Many thanks for the full explanation,

Aaron

  - Original Message - 
  From: Brendan Eich 
  To: Aaron Gray 
  Cc: es-discuss@mozilla.org 
  Sent: Monday, December 01, 2008 1:06 AM
  Subject: Re: Understanding reasons for Harmony


  On Nov 30, 2008, at 10:49 AM, Aaron Gray wrote:


Well as announced in August the ECMAScript 4 language is being heavily 
watered down. Both packages (April)

https://mail.mozilla.org/pipermail/es-discuss/2008-April/006183.html

I cannot actually see what is wrong here, AFAICS package Q's usage of x 
should be an error as x is actually defined in R as external and there is no 
other definition of x in scope. 


  Package Q contains


  import R.*;


  which brings (or should bring) R.x into scope under the name x in Q.


  Note that external does not mean what extern in C means. It was a 
proposed ES4 built-in namespace meaning defined in this package but visible 
outside of it.




Could someone explain or give a better example.


  I can see how the decisions are hard to understand without close reading, 
including knowing what external was proposed to mean (I can't find a trace of 
it in the wiki -- it was cut too well), and thinking through the meaning of 
parenthetical asides such as Lars's consider that public::x is introduced in 
some later file, at a later time and consider flagging the reference to x in 
P as ambiguous.


  Even more important than these fine points was the big-picture point that 
packages were intended to be sugar for namespaces. Lack of a desugaring meant 
ES4 was at risk of being all of late, incomplete, and inconsistent.


  If there were no conflict about the meaning of x in P, then we would have not 
had such a problem.


  Avoiding a conflict by making the reference to x ambiguous (an error) was 
considered arcane because the nesting and order of package fragments should 
not introduce or eliminate such an error. As with namespaces (more below), 
package-based name lookup must agree between compile time and runtime. They 
must not be subject to complicated and hard-to-follow rules.


  Plus, we had a schedule for ES4 that was being slipped with every open 
problem of this order. The right thing to do per sane requirements management 
is to cut, with additions such as the built-in internal namespace added to 
palliate the loss of packages in a future-proof way.


  Therefore the example Lars gave is sufficient -- you don't need a better 
example. That one was sufficient to kill packages as sugar in the time-frame we 
had for ES4.




and now namespaces have been jetisoned too.

https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html

Again could someone give a good example of whats wrong with namespaces.


  The fundamental problem with namespaces was the lack of a module system by 
which to prioritize namespaces during name lookup.


  This need for prioritization (one idea was a first-name-wins reservation 
system) affected both unqualified name lookup due to the extensible global 
object, and name lookup among superclasses.


  Consider just the global object case, with two namespaces, both open in the 
same lexical scope, where a namespace ns is defined at first in only one of 
the namespaces (note how namespaces can qualify namespace names along with 
other names):


  namespace A;
  namespace B;
  use namespace A, namespace B;
  A namespace ns;


  Let's say there's a use of ns to qualify an identifier x, in the same lexical 
scope (top-level content in a script tag, in a web page):


  ... ns::x ...


  Assume x resolves in ns. The question is: what does ns mean? Let's refine the 
reference to be in a function body:


  function foo() {
... ns::x ...
  }


  and close this lexical scope (program defined as a script tag's inline 
content or out-of-line src=URL content). Then in a later program evaluated in 
the same global object, we add


  B namespace ns;
  foo();


  What effect, if any, does the B::ns namespace have on the meaning of ns::x in 
foo's body?


  We don't want any effect, even an ambiguity error -- otherwise name integrity 
is gone and information leaks if not hijacking attacks are too easy. Lexical 
scope means the name lookoup judgments at compile time and runtime should 
agree, and foo's scope should be static in all senses.


  But how do we implement this? ES4 had only the reservation system idea 
whereby:


  A namespace ns;


  would reserve ns in *all* namespaces, even ones not seen yet, for the life 
of the global object being mutated by the definitions. This was considered 
broken-as-designed.


  An alternative would treat each top-level scope as a module, either by giving 
it its own global object (as is done in AS3, IIRC), or at least a subjective 
prioritization mechanism by which to make ns mean only A::ns when used in 
foo, no matter what B::ns might be defined later

Understanding reasons for Harmony

2008-11-30 Thread Aaron Gray
Well as announced in August the ECMAScript 4 language is being heavily watered 
down. Both packages (April) 

https://mail.mozilla.org/pipermail/es-discuss/2008-April/006183.html

I cannot actually see what is wrong here, AFAICS package Q's usage of x 
should be an error as x is actually defined in R as external and there is no 
other definition of x in scope. 

Could someone explain or give a better example.

and now namespaces have been jetisoned too.

https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html

Again could someone give a good example of whats wrong with namespaces.

Many thanks in advance,

Aaron
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Newbie Q's

2008-11-29 Thread Aaron Gray
Hi,

I have been beginning to read the ML reference implementation and have a few 
basic questions.

What is REPL and what does it stand for ?

What is a RIB and does it stand for anything ?

What are FIXTURES ?

Many thanks in advance,

Aaron
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss