I just spoke to Allen and need to make a correction the post above:
computed properties were, in fact, later dropped.
Rick
On Fri, Sep 14, 2012 at 5:34 PM, Irakli Gozalishvili rfo...@gmail.comwrote:
Hey Dean,
I also really love clojure protocols and in fact tried to propose few
extensions
The real point I'm trying to make is that Name objects give us something
akin to clojure's protocols. Imagine an orm protocol -- this is just a
set of names that must exist on an object (or its proto chain). An object
can implement any number of protocols (or interfaces, or whatever) without
On Fri, Sep 14, 2012 at 12:58 PM, Kevin Smith khs4...@gmail.com wrote:
The real point I'm trying to make is that Name objects give us something
akin to clojure's protocols. Imagine an orm protocol -- this is just a
set of names that must exist on an object (or its proto chain). An object
can
On Thu, Sep 13, 2012 at 5:46 PM, Dean Landolt d...@deanlandolt.com wrote:
On Thu, Sep 13, 2012 at 2:59 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Sep 13, 2012 at 1:46 PM, Dean Landolt d...@deanlandolt.comwrote:
On Thu, Sep 13, 2012 at 12:09 PM, Erik Arvidsson
Hey Dean,
I also really love clojure protocols and in fact tried to propose few
extensions for private names to make them little more usable as such:
https://mail.mozilla.org/pipermail/es-discuss/2012-June/023657.html
https://gist.github.com/2967124
Unfortunately thread did not got any
It all start because of a fundamental missing piece in the language that
is the ability to add a private property to an object. Not socially private
as per the _field convention. I mean actually private, enforced by the
runtime.
I've been pondering this for a while now, and I think I've
On Thu, Sep 13, 2012 at 8:37 AM, Kevin Smith khs4...@gmail.com wrote:
1) Is method name-collision a practical problem, or just a theoretical
problem? If it's just a theoretical problem, then we don't need unique
names, and in teaching the language we can simply guide users away from
trying to
On Thu, Sep 13, 2012 at 12:09 PM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
On Thu, Sep 13, 2012 at 8:37 AM, Kevin Smith khs4...@gmail.com wrote:
1) Is method name-collision a practical problem, or just a theoretical
problem? If it's just a theoretical problem, then we don't need unique
Another good example where this is a problem is on prototype chains, a
good example of which you parenthetically noted (iterators). With unique
names it becomes feasible to hang any properties and methods you want off
of prototypes without worrying about collision. For instance, imagine an
On Thu, Sep 13, 2012 at 1:46 PM, Dean Landolt d...@deanlandolt.com wrote:
On Thu, Sep 13, 2012 at 12:09 PM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
On Thu, Sep 13, 2012 at 8:37 AM, Kevin Smith khs4...@gmail.com wrote:
1) Is method name-collision a practical problem, or just a
On Thu, Sep 13, 2012 at 2:59 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Sep 13, 2012 at 1:46 PM, Dean Landolt d...@deanlandolt.comwrote:
On Thu, Sep 13, 2012 at 12:09 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Thu, Sep 13, 2012 at 8:37 AM, Kevin Smith
2012/8/27 David Bruant bruan...@gmail.com
Le 27/08/2012 21:22, Kevin Smith a écrit :
On the other hand, private names seem to add complexity to proxies
A huge share of this complexity has been removed in recent discussions
[1]. Conclusions seem to have reach consensus on es-discuss, but
Apologies in advance for the length...
A huge share of this complexity has been removed in recent discussions
[1]. Conclusions seem to have reach consensus on es-discuss, but nothing
has been officially accepted by TC39
As I understand it, the solution arrived at was to provide a (possibly
Le 28/08/2012 15:38, Kevin Smith a écrit :
Apologies in advance for the length...
Don't. We're here to discuss as the mailing-list name suggests. And if
what you need to say is long, so be it.
A huge share of this complexity has been removed in recent
discussions [1]. Conclusions
Unique (non-private) names offer mixins without collisions. But any
general mixin utility will fail if the source object relies on privately
named methods for its functionality:
...
Neither the destination object nor the library function mixin has access
to the private name, and therefore the
Le 27/08/2012 15:34, Matthew Robb a écrit :
I'm trying to determine whether when compiling into ES3/5 you could
get away with not attaching some .__privates__ property to the object
and instead just put a closure around the definitions.
For that question, the answer is you cannot. You cannot
A name object is not much different from using a string:
let myname1 = S4u-1_tlzUI;
let myname2 = new Name();
someobj[myname1] = 123;
someobj[myname2] = 123;
// In a constructor or method:
this[myname1] = abc;
this[myname2] = abc;
You can pass both around and create properties on any
SO it has to be constructed via new Name() or will it automatically create
Name objects when it encounters an assignment of that form? If you do have
to create it does that mean in order to access it at all you would need to
be in scope of myname2?
My question I think boils down to whether access
On Aug 27, 2012, at 16:55 , Matthew Robb matthewwr...@gmail.com wrote:
SO it has to be constructed via new Name() or will it automatically create
Name objects when it encounters an assignment of that form? If you do have to
create it does that mean in order to access it at all you would
AH okay thanks guys, questions answered!
On Mon, Aug 27, 2012 at 11:03 AM, Axel Rauschmayer a...@rauschma.de wrote:
On Aug 27, 2012, at 16:55 , Matthew Robb matthewwr...@gmail.com wrote:
SO it has to be constructed via new Name() or will it automatically create
Name objects when it
So why could this not desugar to?:
var myClass = (function(){
var __test;
function myClass() {
__test = 0;
}
myClass.prototype.getTest = function(){ return __test; }
return myClass;
})();
On Mon, Aug 27, 2012 at 11:01 AM, David Bruant bruan...@gmail.com wrote:
Le
Hi Matthew,
Sorry, I mislead you. Let me retry:
class myClass{
private test;
constructor(){
this[test] = 0;
}
getTest(){return this[test]};
}
desugars to:
var myClass = (function(){
var test = new Name();
function
I know this has some serious ugly to it but in the spirit of knowing what
COULD potentially create the expected behavior, would this not do the trick?
var myClass = (function(){
function myClass(){
var __priv = Object.create(this);
var __this = __priv.__this =
Le 27/08/2012 19:54, Matthew Robb a écrit :
I know this has some serious ugly to it but in the spirit of knowing
what COULD potentially create the expected behavior, would this not do
the trick?
var myClass = (function(){
function myClass(){
var __priv =
A last alternative is to associate private data via a WeakMap (it can be
shimmed in ES5 with the same garbage collection properties and with good
performances) that inherited functions all have access to. It works, but
it's burdensome and doesn't read as well as object properties.
On the
In the end I am not looking for reads well, I am looking for minimal
semantic difference that can ideally work as a target for compiling to es3.
I am PREFERRING to not have functions as ownProperties. I can't use hard
binding because if the function is assigned to some place else it should no
Le 27/08/2012 21:22, Kevin Smith a écrit :
A last alternative is to associate private data via a WeakMap (it
can be shimmed in ES5 with the same garbage collection properties
and with good performances) that inherited functions all have
access to. It works, but it's burdensome
On Monday, August 27, 2012 at 3:34 PM, Matthew Robb wrote:
In the end I am not looking for reads well, I am looking for minimal semantic
difference that can ideally work as a target for compiling to es3. I am
PREFERRING to not have functions as ownProperties. I can't use hard binding
28 matches
Mail list logo
