Thanks for pointing out to Joose! A powerful class system indeed. I think I'll borrow some features.
Here is my humble opinion on Joose. Simple things are complicated My main concern is that simple things are necessarily complex. I'm talking about member definitions. For example, even if you have a trivial class, you have to put your methods inside the "methods" property. The defineClass description says "Simple yet powerful" which implicates that simple things must not be complicated just because the system also supports complex things. defineClass's syntax is scalable: you don't complicate your simple classes from the start, but in the same time the syntax can express more complex things later. Aspects are smeared across a class/role definition Beside unnecessary complication the syntax make a programmer to put semantically related members far from each other in code. Methods are defined in the "methods" property, attributes are defined in "has", method overrides are in "overrides", different types of attributes are in "has" and "have". As a result, for example, I can't put some semantically related methods and attributes together because I have to put them in different "builders". Thus an aspect consisting of several members may be smeared across entire class definition. Method overrides I wonder why method overrides are put to "overrides" builder. Besides unnecessary complexity and aspect smearing, it is inconsistent with attribute overriding: to override an attribute you need to just re-declare it. Method overriding syntax could be the same. Attributes Overall I like them. I was planning to implement attributes before, and now I see some features that I'd like to borrow. However, there is design a decision that I find dangerous: a constructor parameters are generated based on the order of "has" attributes. This is dangerous because the order of properties in a hash is not guaranteed. See this <http://goo.gl/hdv7b> StackOverflow answer (see the Update of the best answer) and an issue in Chrome <http://goo.gl/jd700> (the order is inconsistent across Chrome versions) *Around* method modifier - In its simplest form an "around" modifier can be achieved with simple method overriding, so it is unnecessary. - The signature of a modified method is changed: the "original" parameter is pushed to the beginning. This is not very good. - Python-like Decorators<https://github.com/nodirt/defineClass/wiki/Decorators> in defineClass do the same but they are more powerful: - You can extract a decorator and *reuse* it in any classes/trait you want - A decorator can have options, so each decorator application can be different - The signature in code is not changed - A class decorator can be applied to a whole class/trait. For example, you can apply "logging" decorator to all methods of a class. I'm not sure Joose has it. - Decorator allow keeping semantically related methods and their decorators together *Augment* method modifier A nice thing. Although an INNER may be only one and the modifier* *can't help you if you need to extend a base method in two points, it is still helpful in simple cases. I may even borrow it. *Before *and* after* method modifier 1. I'm not sure they are needed. They can be replaced with standard method overriding, so they don't add much. Introducing new concepts for sake of adding minor syntax sugar seems wrong to me. At least I don't know any serious PL that has them. I follow "There should be one-- and preferably only one --obvious way to do it." principle from The Zen of Python <http://www.python.org/dev/peps/pep-0020/>. BTW it contains other rules that are broken in Joose, such as "Simple is better than complex.". 2. They smear the aspects even further. 3. Their order in the class definition matters, but a framework cannot rely on it because js specs do not guarantee the order. Roles As far as I understand, a role cannot "do" other roles. defineClass traits can: var T1 = defineClass.trait({ // ... }); var T2 = defineClass.trait({ // ... }) var T3 = defineClass.trait({ _super: [T1, T2] // ... }); -Nodir On Fri, May 25, 2012 at 1:44 AM, Shogun <[email protected]> wrote: > You should look at Joose, great class system. > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
