Note that value object proposal does _not_ address int64.
On Tue, Apr 8, 2014 at 1:27 AM, Waldemar Horwat walde...@google.com wrote:
On 04/02/2014 07:32 AM, Niko Matsakis wrote:
I just wanted to let people on es-discuss know about two of my recent
blog posts concerning typed objects. The
Note that value object proposal does not address int64.
FWIW, I'm too interested in solving the int64 problem somehow. The last I
heard about int64 was here:
http://www.slideshare.net/BrendanEich/value-objects2. How does the int64
story move forward?
--
Cristian Petrescu-Prahova | Software
int64 and uint64 are integral parts of value objects, first proofs of
concept even. Sorry I fell behind on the SpiderMonkey bug, I'm hoping
others will take it over (cc'ed; and for V8) and revive it. It has
obvious use-cases in Node.js and anything that tiles the OS syscall surface.
/be
On 04/02/2014 07:32 AM, Niko Matsakis wrote:
I just wanted to let people on es-discuss know about two of my recent
blog posts concerning typed objects. The first is a kind of status
report:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/typed-objects-status-report/
and the second
Given that Color is a struct type object, is there a more direct way of
getting the common prototype of all the array type objects with different
dimensions with this element type, than by calling
getPrototypeOf(Color.arrayType.prototype)?
___
es-discuss
On 2 April 2014 20:26, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The current
discussion in your article confuses semantics with implementation when it
speaks of typed objects comparing structurally. Typed objects have identity,
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg rossb...@google.comwrote:
On 2 April 2014 20:26, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The current
discussion in your article confuses semantics with implementation when it
On 3 April 2014 09:00, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg rossb...@google.com
wrote:
On 2 April 2014 20:26, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The
current
discussion
On Thu, Apr 3, 2014 at 9:40 AM, Andreas Rossberg rossb...@google.comwrote:
You'd have to unwrap the whole fat pointer, right?
Yes, of course. I simplified a bit.
___
es-discuss mailing list
es-discuss@mozilla.org
On Thu, Apr 3, 2014 at 3:00 AM, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg rossb...@google.com
wrote:
A uvalue is deeply uvalue only when its prototype and all the methods
found
there are uvalues. Although this is the case for E, the
On 3 April 2014 14:57, C. Scott Ananian ecmascr...@cscott.net wrote:
You can never compare uvalues from different realms: both uvalues need
to be in the same realm before you can do the comparison. All you
need is that equal uvalues in realm A become equal uvalues in realm B
when passed over.
Le 3 avr. 2014 à 07:33, Andreas Rossberg rossb...@google.com a écrit :
Not sure what type 'object' is used for in the wild.
I sometimes use it for distinguishing between Object-like objects and
primitive values (usually together with an additional test for excluding
`null`).
For that
On Thu, Apr 3, 2014 at 3:09 PM, Andreas Rossberg rossb...@google.comwrote:
Unfortunately, that only works for primitives because the respective
constructor/wrapper class is known to exist in all realms, it is known
to be the same everywhere, and because the language can hence apply
some
On Thu, Apr 3, 2014 at 9:09 AM, Andreas Rossberg rossb...@google.com wrote:
On 3 April 2014 14:57, C. Scott Ananian ecmascr...@cscott.net wrote:
Unfortunately, that only works for primitives because the respective
constructor/wrapper class is known to exist in all realms, it is known
to be the
On 3 April 2014 15:30, Marius Gundersen gunder...@gmail.com wrote:
On Thu, Apr 3, 2014 at 3:09 PM, Andreas Rossberg rossb...@google.com
wrote:
Unfortunately, that only works for primitives because the respective
constructor/wrapper class is known to exist in all realms, it is known
to be the
On 3 April 2014 15:39, C. Scott Ananian ecmascr...@cscott.net wrote:
On Thu, Apr 3, 2014 at 9:09 AM, Andreas Rossberg rossb...@google.com wrote:
On 3 April 2014 14:57, C. Scott Ananian ecmascr...@cscott.net wrote:
Unfortunately, that only works for primitives because the respective
I just wanted to let people on es-discuss know about two of my recent
blog posts concerning typed objects. The first is a kind of status
report:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/typed-objects-status-report/
and the second details some (preliminary) thoughts on how one
On 2 April 2014 16:32, Niko Matsakis n...@alum.mit.edu wrote:
I just wanted to let people on es-discuss know about two of my recent
blog posts concerning typed objects. The first is a kind of status
report:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/typed-objects-status-report/
On Wed, Apr 2, 2014 at 5:01 PM, Andreas Rossberg rossb...@google.comwrote:
Other properties, like the ability to use an object as keys in weak
collections, follow from that. If we suddenly allowed objects that do
not have identity, but a structural notion of equality, then we could
not allow
On Wed, Apr 2, 2014 at 7:32 AM, Niko Matsakis n...@alum.mit.edu wrote:
I just wanted to let people on es-discuss know about two of my recent
blog posts concerning typed objects. The first is a kind of status
report:
I really appreciate you guys making === (not just ==) work for value types. I
think that drastically improves the usability compared to earlier proposals.
I can see Andreas's concerns regarding what that means for their object-ness
though. But hopefully that can be worked out while still
I just got to the Appendix B at the end of your article, so I see you were
aware of the strictness issue. The semantics of a failed assignment to a
field of a value type should indeed just be the semantics of a failed
assignment: if the assignment is performed by sloppy code, the failure is
Commenting on this same region:
```
print(points[0].x); // 0 to start
points[0].x = 1;
print(points[0].x); // still 0
points[0] = {x: 1, y: 2};
print(points[0].x); // now 1
```
There's no reason why we couldn't extend the grammar to handle this
case, in the same way that `a.f()` has different
quick feedback
1. paper: all Cartesian examples forget to retrieve/assign this.x and
this.y, i.e. `Cartesian . prototype .toPolar = function() {var r =
Math.sqrt(x*x + y*y);}` ... I can guess those are initial own properties
but after reading all examples without context I started
I think the idea that value types should be objects would
require stretching the notion of object too far, and violate one of
the fundamental properties that objects currently have.
Certainly this was the idea, though I didn't think of it is as
violating, but rather... stretching. :)
Other
On 4/2/2014 8:01 AM, Andreas Rossberg wrote:
That is very helpful, thanks! I agree with a lot with what you say.
But to expand on my reply to your blog post, I have one fundamental
concern: I think the idea that value types should be objects would
require stretching the notion of object too far,
On Wed, Apr 2, 2014 at 10:37 AM, Niko Matsakis n...@alum.mit.edu wrote:
I think the idea that value types should be objects would
require stretching the notion of object too far, and violate one of
the fundamental properties that objects currently have.
Certainly this was the idea, though
On Wed, Apr 2, 2014 at 8:26 PM, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The current
discussion in your article confuses semantics with implementation when it
speaks of typed objects comparing structurally. Typed objects have
On Wed, Apr 2, 2014 at 9:11 PM, Dmitry Lomov dslo...@chromium.org wrote:
On Wed, Apr 2, 2014 at 8:26 PM, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The current
discussion in your article confuses semantics with implementation
On Wed, Apr 2, 2014 at 9:36 PM, Mark S. Miller erig...@google.com wrote:
You can't recreate a given fat pointer out of thin air. You need at least
the same backing buffer, or something (e.g., another fat pointer) which
retains the same backing buffer.
The backing buffer has generative
On Wed, Apr 2, 2014 at 1:02 PM, Dmitry Lomov dslo...@chromium.org wrote:
On Wed, Apr 2, 2014 at 9:36 PM, Mark S. Miller erig...@google.com wrote:
You can't recreate a given fat pointer out of thin air. You need at least
the same backing buffer, or something (e.g., another fat pointer) which
On Wed, Apr 2, 2014 at 10:17 PM, Mark S. Miller erig...@google.com wrote:
However, I have to quibble with observable. WeakRefs make GC observable.
WeakMaps do not. Running out of memory, or failing to, is not an
observation, since the spec never says when this might or might not occur
What missing expressive capability does this give developers, aside from
overloading of equality?
Obviously, being able to directly represent an int33 (for example) is
useful, but I'm not seeing the motivation behind user-defined value
objects, yet, aside from overloading equality.
On Wed, Apr
On Wed, Apr 2, 2014 at 3:43 PM, Kevin Smith zenpars...@gmail.com wrote:
What missing expressive capability does this give developers, aside from
overloading of equality?
Obviously, being able to directly represent an int33 (for example) is
useful, but I'm not seeing the motivation behind
On 2 April 2014 19:37, Niko Matsakis n...@alum.mit.edu wrote:
Along those lines, user-defined values (uvalues) probably ought to
have the following characteristics:
- uvalues are (shallowly) immutable
- uvalues have no generative identity, and are compared using by-value ===
- uvalues have a
35 matches
Mail list logo
