On Sun, Jun 3, 2012 at 3:52 PM, Daniel Rinehart <[email protected]> wrote:
> I've only glanced at Joose but wanted to mention that before and after
> wrappers are not a new concept. They have existed in Common Lisp
> Object System for some time.
They existed indeed.
> The semantics of before and after
> wrappers is very different from around or traditional method
> overriding.
I'm not sure I understand what do you mean by "very different". I'm not
saying that they are the same thing but aren't *before*, *after* and *around
* special cases of method overriding?
Here they are implemented as method overriding:
var subClass = defineClass({
_super: SuperClass,
doBefore: function (a, b) {
console.log("Doing this before");
return this._super(a, b);
},
doAfter: function (a, b) {
var ret = this._super(a, b);
console.log("Doing this after");
return ret;
},
doAround: function (a, b) {
console.log("Doing this before");
var ret = this._super(a, b);
console.log("Doing this after");
return ret;
}
});
I realize that sometimes you want to reuse a method modifier in other
classes. In this case you can put it to a trait or implement it as a
decorator <http://goo.gl/EjiVR> that can be applied to any method.
Thanks,
-Nodir
> This page provides a brief synopsis of how before, after,
> and around work in CLOS. Given JavaScript's functional nature the
> concepts carry over nicely.
> http://www.aiai.ed.ac.uk/~jeff/clos-guide.html#meth-comb
>
> -- Daniel R. <[email protected]> [http://danielr.neophi.com/]
>
>
> On Sun, Jun 3, 2012 at 3:50 AM, Nodir Turakulov <[email protected]>
> wrote:
> > 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 StackOverflow answer (see the Update of the best answer) and an
> issue
> > in Chrome (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 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
> >
> > 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. BTW
> it
> > contains other rules that are broken in Joose, such as "Simple is better
> > than complex.".
> > They smear the aspects even further.
> > 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
>
> --
> 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
