Re: ES4 draft: Map
Hello :) Ok sorry :) I'm going to search the old discussions about this in the mailing list :) EKA+ :) 2008/2/29, Lars Hansen [EMAIL PROTECTED]: -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *ekameleon *Sent:* 29. februar 2008 11:47 *To:* es4-discuss@mozilla.org *Subject:* Re: ES4 draft: Map Hello :) In AS3 the flash.util.Dictionnary class contains a little argument in the constructor to control the weak references : Exemple : http://www.gskinner.com/blog/archives/2006/07/as3_dictionary.html In ES4 the garbage collector support weak references ? No. This feature is really important for me :) Sorry, but we've discussed this extensively in the past and have decided not to require support for weak references in ES4. --lars To implement a full Event model like AS3 event model based Dom2/3 W3C event model... this feature is important for example :) EKA+ :) 2008/2/29, Lars Hansen [EMAIL PROTECTED]: I'm enclosing the draft for the Map class. Please comment. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: The nature of static properties/methods in parameterized classes
Another strike against the Java way -- maybe only a minor
point -- is that one has to access statics on the
uninstantiated type Cls but one can only create new objects
from the instantiated type Cls.T, hence one has to pass
both objects around, not just one object, if parameterizing
the program over types in the ES3 way.
--lars
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
Sent: 28. februar 2008 18:08
To: es4-discuss@mozilla.org
Subject: The nature of static properties/methods in
parameterized classes
On http://bugs.ecmascript.org/ this is tickets #247, #289.
There are links there to background material.
We've failed to resolve this properly in the trac, but I need
for us to settle this soon (bits of the library depend on the
resolution), so I'm going to try email.
The issue concerns parameterized classes. Consider this class:
class Cls.T {
static var v;
}
Should ES4 follow C++ and C# and say that:
- Cls.v is nonsensical
- You have to write Cls.int.v
- Cls.int.v is different from Cls.bool.v
- The result of
var p = Cls.T
var q = Cls.T
p === q
is always true.
Or should ES4 follow Java and say that:
- Cls.v makes sense
- Cls.T.v is just an undefined value
- The result of
var p = Cls.T
var q = Cls.T
p === q
is implementation-dependent (it's false in the RI).
The former model avoids a pigeon-hole problem in that
each manufactured type Cls.T can behave independently of
any other Cls.Q, with its own set of statics. Furthermore,
it allows T to be used to annotate static properties and
methods of Cls. It becomes possible for static methods
to take into account a type parameter (so meta::invoke
on Map and Vector, used to convert from Object or Array,
can make use of the value type parameter to construct a
properly typed Map).
The latter model may have some usability advantages,
for example, if v is a constant then Cls.v is that
constant regardless of any other context for Cls, and
Map without type parameters can be called as a function
to convert an object to a * - * Map.
Currently ES4 follows Java, this was made explicit at a meeting
about a year ago, though the minutes suggest (I wasn't there)
that perhaps there was an assumption about that model at the
outset. Anyhow the issue was reopened later because the Java
style might be seen to prevent class definitions from containing
useful static namespace and type definitions -- that's what
those two tickets are about -- because the statics would be
properties of the uninstantiated parameterized class, not
of a parameterized class, and any static type member could
capture an uninstanted type parameter name, which appears to
be bad.
Since I'm not sure what the arguments for the Java style
really are, and I know why the other solution appears
to be nice, I tend to dislike what we have now (being of
the Java style), and I went so far as to sneak the C#
style into the overview paper in the guise of meta-objects.
But there might be implementation considerations I don't
understand. Either way, both tickets 247 and 289 remain
open, and I think they are on the critical path for
the library, so let's try to close them.
--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
The optional /hashcode/ argument is a function that takes a key and returns a numeric code for it. This code may be used to find associations more quickly in the map. Two calls to the /hashcode/ function on the same key value must return the same numeric code, and the /hashcode/ function must always return the same numeric code for two objects that compare equal by the /equals/ function. The default value for /hashcode/ is the intrinsic global function |hashcode|. Dost thou desire arbitrary numeric hashcodes or integral ones? Map( object ) When the |Map| class object is called as a function, it creates a new |Map| object from |EnumerableId| to |*|, populating the new |Map| object with the own properties of /object/. Making Map(x) do something specialized like this seems like a bad idea. If x is already a Map, I'd expect Map(x) to be idempotent and return x. Should thou need this functionality, use a static method to get it. Why does get return null instead of undefined when it fails to find an instance? A version of get with a second parameter X that returns X when the value isn't present would be useful. Need a clear() method that deletes all bindings. The iteration protocol makes a copy before starting to iterate. It might be implemented via copy-on-write but I'd like to see how expensive this is. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Default argument values
On 29/02/2008, Lars Hansen [EMAIL PROTECTED] wrote:
What I meant was an assignment operator so that I could write:
{ xProp: x, yProp: y } ?= { xProp: 10, yProp: 20 };
and x and y would be overwritten only if their values were undefined.
C# has a similar operator for conditional assignment which assigns if
the lhs value is null (??= or something like that, I'm offline and
away from my bookshelf right now).
How this fits into default arguments I don't know for sure. I
superficially imagined that ?= would replace = in the parameter list:
function f({ xProp: x, yProp:y } ?= { xProp: 10, yProp: 20 }) ...
The meaning of that should be intuitive and requires fairly lightweight
changes only.
Lest I get myself into another goto problem, I'll make it clear that
I'm not advocating this for ES4. We're IMO past all deadlines for
new design. I'm just thinking out loud, for the benefit of ES5 :-)
Fair enough. Although I also hope optional named arguments will make
an appearance in ES5. (They're quite a priority for me personally.)
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
