On Feb 27, 2008, at 5:33 AM, Lars Hansen wrote:
None of the above speaks to the possibility that decimal might be
a distinct data type in the language, of course, along with
double and int and uint. Such a data type would in our
opinion not be a poor fit for ES4, and as your own
On Feb 27, 2008, at 9:00 AM, Lars Hansen wrote:
Meta-level methods
The predefined namespace meta is used for methods that
participate in
language-level protocols: invocation and property access and
update. A
class that defines meta::invoke is callable as a function (the
meta::invoke
Was decimal ruled out as its own type?
Peter
On Wed, Feb 27, 2008 at 5:58 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Feb 27, 2008, at 5:33 AM, Lars Hansen wrote:
None of the above speaks to the possibility that decimal might be
a distinct data type in the language, of course, along
On Feb 27, 2008, at 10:40 AM, Brendan Eich wrote:
First, nothing's ruled out -- you're asking the wrong guy if you
want Adobe's position, but see Lars's reply to Mike Cowlishaw:
decimal as a type without any implicit literal/operators mode is
still possible,
I should have written without
OK. Decimal type just makes sense to me. And I think this is one case
where I think you can break the rule that says correct type
annotations do not affect the program.
Peter
On Wed, Feb 27, 2008 at 9:10 PM, Dick Sweet [EMAIL PROTECTED] wrote:
A couple of comments from the fellow who did the
There's no such rule in ES4. There are implicit conversions among
primitive number types, and between primitive types and wrapper types,
and those kick in when storing something in an annotated location. So
these two programs are different, and both are correct:
var s = foo
var t = 10.5
Lars is correct. If you can declare decimal literals, that is enough to
get you into decimal arithmetic. The various automatic coercions will
do the rest, though as he said, type annotations could reduce the scope
of errors. You would also need some static methods on decimal like exp
and log,
On Feb 27, 2008, at 3:59 PM, Waldemar Horwat wrote:
I'd like write access to the spreadsheet so we can fill in the
Google column:
http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQgid=2
Also, some features have been omitted from the spreadsheet, such as
tuple types. Are
Brendan Eich wrote:
On Feb 27, 2008, at 3:59 PM, Waldemar Horwat wrote:
I'd like write access to the spreadsheet so we can fill in the Google
column:
http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQgid=2
Also, some features have been omitted from the spreadsheet, such as
On Feb 27, 2008, at 4:48 PM, Waldemar Horwat wrote:
Most of the categories are quite fine-grained in the spreadsheet.
The other kinds of types are in there, so tuples should be listed
as well or the entry renamed Array and Tuple types. It's mighty
confusing otherwise.
Renaming to
Functions can take optional arguments (they have default values) and
rest arguments:
function f(x, y=0) { ... } // y is optional
What is the opinion on Python-style named arguments? i.e.:
def f(x = 0, y = 0):
...
f(y = 2)
The calling syntax for ES4 would obviously have to be
On Feb 27, 2008, at 5:22 PM, Steven Mascaro wrote:
Anyway, I'm sure you know the advantages (and disadvantages?) to
optional named arguments. I was just wondering whether they had been
considered for ES4, or if considered and rejected, then why. I've
searched the wiki and mailing list, but
On Feb 27, 2008, at 6:35 PM, Steven Mascaro wrote:
This is not to knock named parameters, just to explain why they
never
made it into a serious proposal in the modern ES4 era.
That sounds fine. The only thing it misses is interchanging positional
and named parameters, but that's no big
On Feb 27, 2008, at 6:56 PM, Steven Mascaro wrote:
2008/2/28 Brendan Eich [EMAIL PROTECTED]:
function h({p:x,q:y} = {p:3,q:4}) [x,y]
h()
3,4
Unfortunately, it doesn't work when you want to specify a subset of
the optional parameters. e.g.:
h({p:1})
1,
True -- it's not the same as
14 matches
Mail list logo
