Strong encapsulation means that the code implementing an abstraction can
control the visibility of its fields (i.e. where they can be accessed
from), without any loopholes that can be exploited by code outside the
abstraction's scope. Weak encapsulation allows such loopholes. Note that
I
On 2010-12-21 08:27, David-Sarah Hopwood wrote:
The private names and soft field proposals are similar in the
visibility mechanisms they can simulate, but soft fields are slightly
more general. In either proposal, visibility can be restricted to a
particular lexical scope. In the soft fields
On Thu, 16 Dec 2010 23:19:12 +0100, Mark S. Miller erig...@google.com
wrote:
On Thu, Dec 16, 2010 at 1:58 PM, Kris Kowal kris.ko...@cixar.com wrote:
On Thu, Dec 16, 2010 at 1:53 PM, David Herman dher...@mozilla.com
wrote:
function Point(x, y) {
private x, y;
this.x =
Coming from the commonjs perspective I did something similar to create private
data per instance using a closure.
I feed an object literal into a 'type' generator so that:
Type.create('Foo', {
imports: {
log: require('log')
},
specification: {
'private': {
bar: null,
On Mon, Dec 20, 2010 at 9:21 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
I've seen mentions in the recent thread that the goal of the Private
Names proposal was to support private fields for objects. While that may
be a goal of some participants in the discussion, it is not what I would
The ES5.1 draft has been updated with corrections noted on this lists. See
http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
Thanks to David and David-Sarah for careful reading.
Allen
On Dec 15, 2010, at 10:11 AM, Allen Wirfs-Brock wrote:
The process for advancing
See below:
On Dec 21, 2010, at 9:03 AM, Mark S. Miller wrote:
On Mon, Dec 20, 2010 at 9:21 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I've seen mentions in the recent thread that the goal of the Private Names
proposal was to support private fields for objects. While that may be a
On 2010-12-21 08:49, Lasse Reichstein wrote:
On Thu, 16 Dec 2010 23:19:12 +0100, Mark S. Miller erig...@google.com wrote:
On Thu, Dec 16, 2010 at 1:58 PM, Kris Kowal kris.ko...@cixar.com wrote:
On Thu, Dec 16, 2010 at 1:53 PM, David Herman dher...@mozilla.com wrote:
[...]
than
On Dec 20, 2010, at 11:05 PM, David-Sarah Hopwood wrote:
The new equivalence under private names would be x[#.id] === x.id.
... which is strictly weaker, more complex, and less explanatory.
So is a transposed get from an inherited soft field. Soft fields change the way
square brackets work
On Dec 21, 2010, at 12:39 PM, Mark S. Miller wrote:
The promised separate email:
On Tue, Dec 21, 2010 at 10:20 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
It seems to me, the real point of difference here is whether or not we should
add a syntactic mechanism that supports
-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.mozilla.org/pipermail/es-discuss/attachments/20101221/552d2516/attachment.html
--
___
es-discuss mailing list
es-discuss
I never said I don't want syntactic support. I said I don't like the syntax
you proposed. You and Dave have now both said that you consider this to be
the main issue.
Hm, I certainly didn't intend to say that. I'm not quite sure what you're
referring to that I said. I don't necessarily have
On Dec 21, 2010, at 2:52 PM, thaddee yann tyl wrote:
I was very interested when I heard about private names. It seems like
a very good idea. However, the specification that the strawman gives
is harder than I thought it would be.
I am unsure I fully understand this _private names_ proposal.
Just giving my feedback to this (so it's recorded somewhere other than my head).
I find the apparent necessity of conflating syntax and semantics irksome, i'd
much rather that there be two distinct discussions one of syntax and the other
for semantics of soft-fields, private names, gremlins,
On Dec 21, 2010, at 4:01 PM, Oliver Hunt wrote:
Just giving my feedback to this (so it's recorded somewhere other than my
head).
I find the apparent necessity of conflating syntax and semantics irksome, i'd
much rather that there be two distinct discussions one of syntax and the
other
On Dec 21, 2010, at 4:25 PM, Brendan Eich wrote:
On Dec 21, 2010, at 4:01 PM, Oliver Hunt wrote:
Just giving my feedback to this (so it's recorded somewhere other than my
head).
I find the apparent necessity of conflating syntax and semantics irksome,
i'd much rather that there be two
On Dec 21, 2010, at 4:51 PM, Oliver Hunt wrote:
But what is an array index, then? uint32 is not a type in the language.
Would proxy[3.14] really pass a double through?
Yes, I would expect no coercion of any non-object. The reason for
disallowing objects is safety afaik, those arguments
On Dec 21, 2010, at 5:00 PM, Brendan Eich wrote:
On Dec 21, 2010, at 4:51 PM, Oliver Hunt wrote:
But what is an array index, then? uint32 is not a type in the language.
Would proxy[3.14] really pass a double through?
Yes, I would expect no coercion of any non-object. The reason for
On 12/21/2010 04:25 PM, Brendan Eich wrote:
Why does your expectation differ here compared to the following:
MyAwesomeThing.prototype.myCoolFunction = function() {
var cachedHotness = gensym();
if (!this[cachedHotness])
this[cachedHotness] = doExpensiveThing(this)
return this[cachedHotness];
}
On Dec 21, 2010, at 5:09 PM, Oliver Hunt wrote:
On Dec 21, 2010, at 5:00 PM, Brendan Eich wrote:
On Dec 21, 2010, at 4:51 PM, Oliver Hunt wrote:
But what is an array index, then? uint32 is not a type in the language.
Would proxy[3.14] really pass a double through?
Yes, I would expect no
On Dec 21, 2010, at 5:13 PM, David Flanagan wrote:
On 12/21/2010 04:25 PM, Brendan Eich wrote:
Why does your expectation differ here compared to the following:
MyAwesomeThing.prototype.myCoolFunction = function() {
var cachedHotness = gensym();
if (!this[cachedHotness])
On Dec 21, 2010, at 5:57 PM, Brendan Eich wrote:
A use directive feels vaguely more comfortable here to me. It makes it
clearer to the programmer that some kind of magic is going on.
But I confess that I haven't actually read Allen's proposal, so take this
with a grain of salt.
On Dec 21, 2010, at 4:01 PM, Oliver Hunt wrote:
function MyAwesomeThing() {
}
MyAwesomeThing.prototype.myCoolFunction = function() {
if (!this._myCachedHotness)
this._myCachedHotness = doExpensiveThing(this)
return this._myCachedHotness;
}
I see this nifty
On Dec 21, 2010, at 2:12 PM, Brendan Eich wrote:
I also see the ocap purity of soft fields, and I like Mark's
AST-decorated-sparsely soft fields use-case. But we already have weak maps in
harmony:proposals, so one can write such code now, just at some loss of
convenience: without square
On Dec 21, 2010, at 8:17 PM, Allen Wirfs-Brock wrote:
However, why would you bother freezing your AST nodes in the first place.
JavaScript has a great mechanism for soft fields -- it's called properties.
You can even make your base properties non-configurable if you want to. But
why
On Dec 21, 2010, at 9:38 PM, Brendan Eich wrote:
On Dec 21, 2010, at 8:17 PM, Allen Wirfs-Brock wrote:
However, why would you bother freezing your AST nodes in the first place.
JavaScript has a great mechanism for soft fields -- it's called
properties. You can even make your base
On Dec 21, 2010, at 10:14 PM, Brendan Eich wrote:
On Dec 21, 2010, at 10:03 PM, Alex Russell wrote:
This is not a relevant fear in my view. It's also kind of silly given all
the open source JS libraries. If someone did over-freeze, you could stop
using their library, or fork and fix it.
On Dec 21, 2010, at 10:17 PM, Alex Russell wrote:
On Dec 21, 2010, at 10:14 PM, Brendan Eich wrote:
I fear APIs that freeze, only take frozen objects or only have versions that
do, or are so mutability-hostile that they warp our use of the language
toward frozen-by-default constructs.
On 2010-12-21 22:12, Brendan Eich wrote:
On Dec 20, 2010, at 11:05 PM, David-Sarah Hopwood wrote:
Please retain all relevant attribution lines.
Brendan Eich wrote:
The new equivalence under private names would be x[#.id] === x.id.
You said under private names here, but it should actually be
[Resending as you did to the right group, although I filter both to the same
folder and prune dups. Whee! /be]
On Dec 21, 2010, at 10:22 PM, David-Sarah Hopwood wrote:
On 2010-12-21 22:12, Brendan Eich wrote:
On Dec 20, 2010, at 11:05 PM, David-Sarah Hopwood wrote:
Please retain all
30 matches
Mail list logo
