Re: Class method addition and replacement (was Re: AOP Compatibility)
On 06/04/2008, at 1:38 AM, Brendan Eich wrote: Sure, developers will be able to explicitly mark areas in their code which they deem appropriate for another developer to change, but that strikes me as a bit of a fantasy land. The fantasy here would be that JS has been kept down on the same- origin and small-scale storybook farm where it was born. It's in the big city now. ;-) The majority of code which requires patching by external developers was never written to be patched, but people do it anyway. This is good, don't you agree? See above. I'm not denying that the problems you're trying to fix aren't problems, it's just that I believe a wholesale locking down of the language will be too drastic and may result in a shift away from the language Javascripters have come to know and love. To give some context, when you speak of producers consumers of Javascript code I guess I would classify myself as a predominant consumer. You may be surprised to hear that mutability is one of the things that I love about the language, and that I don't particularly want greater integrity properties (despite desiring the side effects :) ). I have experience as both a Javascript Actionscript 3 programmer, so you could say that I've had a little bit of a taste of what's to come. One experience of mine you might be interested in is as a consumer of Adobe's Flex framework. Quite often, I feel the need to extend the various Flex classes (as you do). Unfortunately, many of the classes have properties defined as private instead of protected, despite being clearly suitable candidates for consumers to extend. This results in developers like myself being forced to copy-paste entire classes just to override high integrity properties. In Javascript, this would not be an issue. Do you get the feeling that the majority of developers who aren't writing the Javascript you're talking about will be left with a new language that doesn't fit their development profile? Do you think that the developers who will write large-scale Javascript will cater to those who are used to a more traditional approach? My gut feeling to those two questions are yes and no, but unfortunately that's all it is; a gut feeling. Cheers, -- Nathan de Vries ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Class method addition and replacement (was Re: AOP Compatibility)
On Thu, Apr 3, 2008 at 5:20 PM, Peter Hall [EMAIL PROTECTED] wrote:
If you want mutability, you can define methods as vars in the first place.
class Foo {
// can be modified on a per-instance basis
public var f : function (a:T):S = function (a:T):S {
return null;
}
}
A common idiom is to have a default value in the ADT's prototype. (I'm
calling a constructor-with-a-prototype an ADT -- ES3, which doesn't
have true class classes).
ES3 example:
function Button() { }
Button.prototype = {
ondepress : function(){},
_isDepressed : false
};
var b = new Button;
b.ondepress = buttonDepressed;
- b - just got a new instance property: ondepress.
So when defining an ES4 class, instead of putting a default -
ondepress - in the prototype, a dummy function will be added to the
instance.
I'm not understanding the syntax well enough to post an example.
This will have the result of more function objects being created for a
program that does not use - ondepress - for Button instances. Would
the Button class be better off by having a private EMPTY function? Or
maybe that goes on a larger scale, to the event notification system,
but then that wouldn't work unless the event system's empty Function
instance was immutable.
[snip]
___
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
Dynamic class default (was Re: Class method addition...)
Since you grant use-cases for sealing objects against mutation, are you simply arguing about what the default should be (that 'dynamic class' should not be required to get an extensible-instance factory, that 'class' should do that)? Well if it is up for debate... Can we have classes be dynamic by default, and non-dynamic if the class is declared to be final? I realize that non-dynamic and final are not identical concepts, but they are similar. Keywords surely count towards the complexity budget, this would save us a buck. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Class method addition and replacement (was Re: AOP Compatibility)
On Sun, 2008-04-06 at 13:07 -0700, Brendan Eich wrote: You're doing it again: wholesale locking down is false as a general statement, and almost entirely false broken down into particulars. You're right, wholesale locking down is false. However, it is the migration path for developers who will be using ES4 to its fullest. Since you grant use-cases for sealing objects against mutation, are you simply arguing about what the default should be (that 'dynamic class' should not be required to get an extensible-instance factory, that 'class' should do that)? Yes, dynamic classes seem more in line with my expectations. Perhaps D's concepts of const/invariant [1] could apply as optional class / member decorations available to developers with immutability in mind. No, because as noted above and copiously documented, ES4 is a superset of ES3. It's the superset I'm concerned about (and talking about), mainly because that's the migration path for Javascript developers as I mentioned previously. It seems to me the way forward is to make specific arguments about these proposals, not generalize inaccurately about their being wholesale in effect (they aren't), or untraditional (to the extent that JS authors today try to fake it, they are not). Sure. I'll do my best to do that, keeping in mind that some of the concepts being discussed WRT language design are outside my field of expertise. Cheers, -- Nathan de Vries [1] http://www.digitalmars.com/d/2.0/const3.html ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
DRAFT: Names spec
Please find attached a draft spec that describes how names are structured and resolved in ES4. This is the first of several fundamental sections on the core language. As such it might seem lacking for context. At this early stage of review please use your imagination as much as possible to fill in the gaps. Drafts on syntax, types, values, and execution will be forthcoming in the next few weeks. These will help to complete a bootable image of the core language spec. Thanks in advance for any an all feedback. Jd names.html Description: Binary data ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
