> I heard Gilad Bracha in ECOOP to say [paraphrase] "optional typing is great
> to help with documentation, and to help the tools; but it should not touch
> the runtime". This is what I take for my own as well, nicely said. Your
> overload proposition, though, changes the language so that this
> My personal feeling is that I’d rather ES not have static typing of this
> form. I believe it makes the language substantially more complex, and to me
> it feels best to try to minimize the growth of the language in order to
> ensure that those things that we do add are added in a compatible
Two things:
I heard Gilad Bracha in ECOOP to say [paraphrase] "optional typing is
great to help with documentation, and to help the tools; but it should
not touch the runtime". This is what I take for my own as well, nicely
said. Your overload proposition, though, changes the language so that
Filip Pizlo wrote:
Hi Brandon,
Thanks for writing this up!
My personal feeling is that I’d rather ES not have static typing of this
form. I believe it makes the language substantially more complex, and to
me it feels best to try to minimize the growth of the language in order
to ensure that t
Hi Brandon,
Thanks for writing this up!
My personal feeling is that I’d rather ES not have static typing of this form.
I believe it makes the language substantially more complex, and to me it feels
best to try to minimize the growth of the language in order to ensure that
those things that we
> One of the first complications with types is typeof's behavior. All of
the above types would return their string conversion including bool. (In my
experience "boolean" is seen as verbose among C++ and C# developers.
Breaking this part of Java's influence probably wouldn't hurt to preserve
consist
Matthew Robb schrieb:
What I'd really like to have in the language is the ability to store a
property access into a single binding
Notice that the https://github.com/zenparsing/es-function-bind proposal
does exactly this, at least for methods (and I don't think I would want
it for arbitrary a
On Sun, Jul 19, 2015 at 10:16 AM, Bergi wrote:
> Mark S. Miller wrote:
>
> We've talked about allowing await at the top level of modules, I think so
>> that the await continuation could proceed after the synchronous part of
>> the
>> load. I am unclear on the details and cannot reconstruct a sen
Mark S. Miller wrote:
We've talked about allowing await at the top level of modules, I think so
that the await continuation could proceed after the synchronous part of the
load. I am unclear on the details and cannot reconstruct a sensible story
from memory.
I'd love to see that, using `await`
9 matches
Mail list logo
