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
Crist
> 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 E
Note that "value object" proposal does _not_ address int64.
On Tue, Apr 8, 2014 at 1:27 AM, Waldemar Horwat 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 first is a kin
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 detai
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 3 April 2014 15:39, C. Scott Ananian wrote:
> On Thu, Apr 3, 2014 at 9:09 AM, Andreas Rossberg wrote:
>> On 3 April 2014 14:57, C. Scott Ananian wrote:
>> Unfortunately, that only works for primitives because the respective
>> constructor/wrapper class is known to exist in all realms, it is k
On 3 April 2014 15:30, Marius Gundersen wrote:
> On Thu, Apr 3, 2014 at 3:09 PM, Andreas Rossberg
> 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 same" everywhere, and becau
On Thu, Apr 3, 2014 at 9:09 AM, Andreas Rossberg wrote:
> On 3 April 2014 14:57, C. Scott Ananian 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 same" everywhere, and because the l
On Thu, Apr 3, 2014 at 3:09 PM, Andreas Rossberg 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 same" everywhere, and because the language can hence apply
> some magic to "rebind"
Le 3 avr. 2014 à 07:33, Andreas Rossberg 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 purpose, `typeof` appli
On 3 April 2014 14:57, C. Scott Ananian 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. This is exactly
On Thu, Apr 3, 2014 at 3:00 AM, Dmitry Lomov wrote:
> On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg
> 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 implications for
>> > JS
>> > are, ahe
On Thu, Apr 3, 2014 at 9:40 AM, Andreas Rossberg wrote:
>
> 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
https://mail.mozilla.org/listinfo/es-discuss
On 3 April 2014 09:00, Dmitry Lomov wrote:
> On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg
> wrote:
>>
>> On 2 April 2014 20:26, Mark S. Miller wrote:
>> > We could specify that WeakMaps can use typed objects as keys. The
>> > current
>> > discussion in your article confuses semantics with im
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg wrote:
> On 2 April 2014 20:26, Mark S. Miller 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
On 2 April 2014 20:26, Mark S. Miller 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,
> characterized by the
On 2 April 2014 19:37, Niko Matsakis 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 prototy
On Wed, Apr 2, 2014 at 3:43 PM, Kevin Smith 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 user-defined value
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 10:17 PM, Mark S. Miller 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
> anyway. In fact,
On Wed, Apr 2, 2014 at 1:02 PM, Dmitry Lomov wrote:
>
> On Wed, Apr 2, 2014 at 9:36 PM, Mark S. Miller 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 buffe
On Wed, Apr 2, 2014 at 9:36 PM, Mark S. Miller 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 identity, so the Wea
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 identity, so the WeakMap should hold on
to the backing buffer weakly[1], but it shoul
On Wed, Apr 2, 2014 at 9:11 PM, Dmitry Lomov wrote:
>
>
>
> On Wed, Apr 2, 2014 at 8:26 PM, Mark S. Miller 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 o
On Wed, Apr 2, 2014 at 8:26 PM, Mark S. Miller 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, charac
On Wed, Apr 2, 2014 at 10:37 AM, Niko Matsakis 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 I didn't
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,
> 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. :)
> Oth
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 doub
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 sema
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
silent.
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 keeping
On Wed, Apr 2, 2014 at 7: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/
>
On Wed, Apr 2, 2014 at 5:01 PM, Andreas Rossberg wrote:
>
> 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 these objects
On 2 April 2014 16:32, 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 se
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 could
36 matches
Mail list logo
