Re: Javascript Class Specification: seek discussion in this email group.

hi, I am glad to see a other survivor in the email group.

I've read the ECMA6 document, also read commonJS or requireJS.ECMA6 too far
away, commonJS can not solve the fine-grained class dependent and loading
demand.

I‘ve learn JDK class loading system and propose JCS. "Let Javascript like
Java". ECMA6 doing it. The future, if we want JS language to be the first
cloud language,not the first scripting language, you have to do it.

I also thought about whether to compatible commonJS or requireJS. But I
found it completely different from the conceptual layer: JSDK based on
classes, commonJS based on modules, obviously the latters much more coarse
granularity. If want really compatible, need to insert coarse-grained
module syntax of commonJS or requireJS in a fine-grained JSDK class code,
very difficult. Whether I should compromise with commonJS, I have not fully
decided.

JSDK let Javascript more like JDK micro core, not a big Java.
Something new:
1. An unified minimum core class system, namespace is JS. Avoid everyone
write their own "core".
2. Encourage full OO programming. The function style shouldn't be used in
open JS class libraries.
3. Has the most fine-grained file loader. There is no so-called "module",
there is only "package and class"; no module-loader, just has class-loader.
You can define your loader for loading class files instead of the default
loader.
4. Mutil-classloader allows load multiple versions of the same name class.
Ext has only one class loader.

If you have already defined class but order to use commonJS, you still need
to define the module's exports and imports. JCS does not require you to do
so, define classes and class dependencies, load class, everything is very
clean.


FengChun


2013/1/31 Sam L'Ecuyer <samlecuyer@gmail.com>

> Hi Feng Chun,
>
> There actually is a class definition discussion going on in the language
> spec team, here:
> http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes
>
> Apart from that, however, I'm going to have to respectfully disagree on
> the role of such a complex class system as you've proposed in preference of
> the CommonJS module definition.  I recommend that you read it.
>
>  http://www.commonjs.org/specs/modules/1.0/
>
> The CommonJS module definition is small, portable, and, most importantly,
> keeps Javascript Javascript.  The Java class system is overly verbose, and
> even the dojo project (which used to use a very Java-like name-spacing) has
> moved to the simpler require() system.
>
>
> What is it that the JSDK you've proposed brings to the table that is
> missing from existing module schemes?  Is it something new, or is it just
> Java?
>
> Cheers,
> Sam
>
>
>
> On Tue, Jan 29, 2013 at 12:33 AM, chun feng <fengchun.china@gmail.com>wrote:
>
>> Too quiet here.And nothing mails.
>> I thought the people here are specification lovers or senior developers.
>>
>> If someone is really interested in the JS class specification, then
>> please join my document discussions, tell me your opinion.Today I just
>> updated it: https://github.com/fch415/jtdk/blob/master/jcs_en.md.
>>
>>
>> Sincerely,
>> Feng Chun
>>
>
>
>
> --
> Thanks,
> Sam L'Ecuyer
>