In trying to update my JS approach I looked into 'traits'. I'm still on the
fence about using them at this stage, but MarkM was asking for feedback of
pretty much any kind so here is a little.
I believe I understand traits for the most part just from the info on the
Web site:
http://traitsjs.org/
On Tue, Oct 4, 2011 at 10:36 PM, Dean Landolt wrote:
>
>
> On Tue, Oct 4, 2011 at 5:12 PM, John J Barton > wrote:
>
>>
>>
>> On Tue, Oct 4, 2011 at 12:59 PM, Bob Nystrom wrote:
>>
>>>
>>> A constructor is different from a regular function. Instead of returning
>>> the value that the body of the
On Tue, Oct 4, 2011 at 5:12 PM, John J Barton
wrote:
>
>
> On Tue, Oct 4, 2011 at 12:59 PM, Bob Nystrom wrote:
>
>>
>> A constructor is different from a regular function. Instead of returning
>> the value that the body of the function returns, it returns a special
>> newly-created object.
>>
>
>
Le 04/10/2011 18:51, Mike Samuel a écrit :
> 2011/10/4 David Bruant :
>> Le 03/10/2011 22:49, Andrea Giammarchi a écrit :
>>> Dear All,
>>>while I had the opportunity to ask directly to Brendan Eich this
>>> question, I would like to ask you 5 minutes of your precious time to
>>> understand com
On Tue, Oct 4, 2011 at 2:12 PM, John J Barton
wrote:
>
>
> On Tue, Oct 4, 2011 at 12:59 PM, Bob Nystrom wrote:
>
>>
>> A constructor is different from a regular function. Instead of returning
>> the value that the body of the function returns, it returns a special
>> newly-created object.
>>
>
>
On Tue, Oct 4, 2011 at 4:09 PM, Sean Eagan wrote:
> On Mon, Oct 3, 2011 at 5:11 PM, Allen Wirfs-Brock
> wrote:
>> as it currently stands, a function is allowed to use both:
>>
>> function f(a,b,c,...rest) {
>> g(...arguments);
>> h(...rest);
>> }
>
> Rest parameters are capable of anything
On Tue, Oct 4, 2011 at 12:59 PM, Bob Nystrom wrote:
>
> A constructor is different from a regular function. Instead of returning
> the value that the body of the function returns, it returns a special
> newly-created object.
>
Sorry, already you lost me ;-) I guess you mean the operand of "new"
On Mon, Oct 3, 2011 at 5:11 PM, Allen Wirfs-Brock wrote:
> as it currently stands, a function is allowed to use both:
>
> function f(a,b,c,...rest) {
> g(...arguments);
> h(...rest);
> }
Rest parameters are capable of anything arguments objects are and
more, so what use case would there eve
On Tue, Oct 4, 2011 at 10:52 AM, Mikeal Rogers wrote:
My main concern with *some* of the proposals is that I feel they add
> features and clever syntax for experts at the expense of keeping the
> language easy to understand for new programmers.
It's hard to satisfy both sets of users here. It's
s/"not taking as inspiration"/"now taking as inspiration"
sorry for the typos, it's been a long hot day on this side of the world.
On Tue, Oct 4, 2011 at 6:56 PM, Mikeal Rogers wrote:
> s/restructuring/destructuring
>
>
> On Tue, Oct 4, 2011 at 6:52 PM, Mikeal Rogers wrote:
>
>> Maybe it's time
+1
On Tue, Oct 4, 2011 at 10:52 AM, Mikeal Rogers wrote:
> Maybe it's time for me to chime in.
>
> While I find it facilitating that so much meaning is being found in my
> tweet I thought it might be productive to say what I actually meant by the
> comment.
>
> JavaScript's current (ECMA5) syntax
s/restructuring/destructuring
On Tue, Oct 4, 2011 at 6:52 PM, Mikeal Rogers wrote:
> Maybe it's time for me to chime in.
>
> While I find it facilitating that so much meaning is being found in my
> tweet I thought it might be productive to say what I actually meant by the
> comment.
>
> JavaScrip
Maybe it's time for me to chime in.
While I find it facilitating that so much meaning is being found in my tweet
I thought it might be productive to say what I actually meant by the
comment.
JavaScript's current (ECMA5) syntax has never prevented me from building an
application. I find coffeescri
2011/10/4 Russell Leggett :
> On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel wrote:
>
>> No it doesn't.
>>
>> Just walk the object graph starting from the root object and let the
>> set of all reachable symbols be A.
>> Load jQuery
>> Walk the object graph again letting the set of all reachable symb
On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel wrote:
> No it doesn't.
>
> Just walk the object graph starting from the root object and let the
> set of all reachable symbols be A.
> Load jQuery
> Walk the object graph again letting the set of all reachable symbols be B.
>
> The public API of jQuer
2011/10/4 David Bruant :
> Le 03/10/2011 22:49, Andrea Giammarchi a écrit :
>>
>> Dear All,
>> while I had the opportunity to ask directly to Brendan Eich this
>> question, I would like to ask you 5 minutes of your precious time to
>> understand common concerns from the JS community, summarized
I am on mobile so it's short one ... subclassing does not need new syntax,
it needs eventually a fix on Object.create or a similar method. However,
subclassing will always suffer cross frame issues, isn't it so how a
triangle can magically solve this specific problems is a mystery to me but
I'll be
On Tue, Oct 4, 2011 at 6:16 AM, David Bruant wrote:
>
>
> Why aren't there that many good JavaScript IDEs? Because JavaScript is
> ridiculously hard to analyse. It is weakly typed, and highly dynamic.
>
As we have discussed here before, good IDEs have be created for weakly
typed dynamic languag
On Oct 3, 2011, at 9:18 PM, Russell Leggett wrote:
>
> On the other hand, I'd also hate to see ES4 part 2.
>
Having been there I can assure you that the current state of ES.next
development is nothing like ES4. The most import difference is that ES4
incorporated core concepts that were stil
Le 04/10/2011 17:03, Andrea Giammarchi a écrit :
David, as I have tweeted before, syntax is a non problem, surely is
not a problem *now* because you already have alternatives such
CoffeeScript, GWT, Traceeur or any sort of transpiler you want ... do
all these new syntax bring real benefits to J
On Mon, Oct 3, 2011 at 9:18 PM, Russell Leggett
wrote:
>
> As much as every JavaScript advocate usually cringes at the comparison
> of JavaScript to Java, it is a little funny that right now I think
> they are in a little bit of the same situation. The JVM and JavaScript
> are both becoming highly
On Oct 4, 2011, at 12:44 AM, Brendan Eich wrote:
> On Oct 4, 2011, at 5:43 AM, Russell Leggett wrote:
>
>> I don't want to be pushy, so this is the last time that I'll mention
>> it, but if we can create something using the <| operator that can
>> basically do what has been discussed for the sim
David, as I have tweeted before, syntax is a non problem, surely is not a
problem *now* because you already have alternatives such CoffeeScript, GWT,
Traceeur or any sort of transpiler you want ... do all these new syntax
bring real benefits to JavaScript ?
I am not sure, I never needed new syntax
Le 04/10/2011 15:43, Kyle Simpson a écrit :
I'm sorry David, I just have to express a dissenting opinion here.
There is no reason to be sorry. As I said at the end, we are different
within the same community. We have different need and views and
consequently, sometimes disagree. That's fine, le
Yes, tools should be better, but they need to start becoming better by
themselves as previous discussions here have noted.
However, there are problems in the language that need to be addressed by
both syntax and APIs. We need:
- A sane way of dealing with equality, identity and basically a lot of
I'm sorry David, I just have to express a dissenting opinion here. While I
could see that "better tooling!" would be a positive side-effect of some
syntax suggestions, I think it's a overreaching idea to consider such a main
argument for adding new syntax.
You make a compelling argument of how
I'm sorry David, I just have to express a dissenting opinion here. While I
could see that "better tooling!" would be a positive side-effect of some
syntax suggestions, I think it's a overreaching idea to consider such a main
argument for adding new syntax.
You make a compelling argument of how
On Tue, Oct 4, 2011 at 3:44 AM, Brendan Eich wrote:
> On Oct 4, 2011, at 5:43 AM, Russell Leggett wrote:
>
> I don't want to be pushy, so this is the last time that I'll mention
> it, but if we can create something using the <| operator that can
> basically do what has been discussed for the simpl
Le 03/10/2011 22:49, Andrea Giammarchi a écrit :
Dear All,
while I had the opportunity to ask directly to Brendan Eich this
question, I would like to ask you 5 minutes of your precious time to
understand common concerns from the JS community, summarized under my
point of view in this post:
In database world enums are uint/ushort (up to 0x) and two enums may
conflicts due same order but this has never been a problem.
var Enum = (function () {
"use strict";
function assign(name, i) {
this[name] = i + 1;
}
var
forEach = [].forEach,
freeze = Object.freeze || func
Brendan, thanks for the follow up, I also discovered the existence of
bettween, great!
Russel,
ES4 part 2 is what I'd like to avoid too and this is my point indeed.
I am not saying that let, yeld, {block scope}, and destructuring is not
welcome and cool, these are all part already available s
On Oct 4, 2011, at 5:43 AM, Russell Leggett wrote:
> I don't want to be pushy, so this is the last time that I'll mention
> it, but if we can create something using the <| operator that can
> basically do what has been discussed for the simplest class literal,
I think you're barking up several wr
On Oct 4, 2011, at 2:37 AM, Erik Arvidsson wrote:
> On Mon, Oct 3, 2011 at 17:25, Brendan Eich wrote:
>> If so we are at an impasse. To get past it, we would need to agree on
>> declarative syntax and semantics preventing use before initialization. We
>> can try to do that again, see if anyone
33 matches
Mail list logo