Here is a Pastie link to a concrete example.
http://pastie.textmate.org/90584
Alex Arnell
PS. Sorry, I forgot to start new thread when I started these replies.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On Aug 22, 2:11 pm, Mislav Marohnić [EMAIL PROTECTED]
wrote:
On 8/22/07, ben [EMAIL PROTECTED] wrote:
Anyway, to each his own. I'm guessing your friends balked at the
self.prototype.instanceMethod = function() {...} syntax. That bit can
be improved, I think. If you use the closure
Hey Alex, et al.,
I'm inclined to agree with Jeff on this point, so I hope there's a way
of making the syntax sweeter.
Yes, the very first version I wrote did in fact do that. I changed it
on the advice of some friends after they looked at the syntax.
Do you remember what offended your
Alex, I like the class definition function method with the exception
of returning a hash. It seems like it ought to be one way or the
other. But then, I've never had any problem just going long-hand with
my class definitions.
One small quibble, I think it might be a little more clear were
On Jul 11, 10:18 am, Jeff Watkins [EMAIL PROTECTED] wrote:
Alex, I like the class definition function method with the exception
of returning a hash. It seems like it ought to be one way or the
other. But then, I've never had any problem just going long-hand with
my class definitions.
1. Does the current API make sense? Was there anything about it that
surprised you? Anything you'd add or remove?
Personally I am quite fond of the current API (for obvious reasons).
I especially like Class.add addition, although I think it might make
more sense represented as Class.reopen
Going to add my two cents here. I didn't read the entire thread, so
hopefully this isn't irrelevant by now. :-)
I think asking people what you should name something is a waste of
time. It's largely a subjective issue, just pick a name and go with
it, but using $ as a prefix is nasty and breaks
H, ok, reading over all the discussion, how about using Class for
everything and kind of yield the new class around? Like so:
Class.extending(ParentClass).including(Enumerable,
Comparable).create({
initialize: function() { ... },
...
}).aliasing({
anAlias: aliased,
...
});
All of
On Jun 29, 8:22 pm, Tobie Langel [EMAIL PROTECTED] wrote:
How is Class a constructor ?
Constructor in JavaScript is a function, which called with
var someObject = new someFunction();
returns an object, which behaves similar to all objects created the
same way.
So in my implementation (as in
On Jun 29, 8:22 pm, Tobie Langel [EMAIL PROTECTED] wrote:
Properties applied to it's prototype aren't available on the
instances.
My implementation breaks this 'chain' (properties from 'prototype'
accessible in objects created by 'new'), so I had to recreate it
myself.
PS. Sorry for my
Hi DK,
Well that's really exciting! And might allow us to have dynamic class
methods.
I'll have a better look at it as soon as possible - I'm in the middle
of a move right now so it's a bit cmplicated.
Thanks fro your report,
Tobie
On Jun 29, 4:54 am, DK [EMAIL PROTECTED] wrote:
On Jun 25,
While doing that, we're embracing some
already established conventions from other languages in order not to
re-invent everything.
With that quote I want to reiterate that MooTools already has
Inheritance.
Its inheritance mechanism was also developed from Dean Edwards' Base
class.
MooTools has
Not in direct reply to anything being said on this thread, but more of
a few suggestions.
In PHP4, the initialising method had the same name as the class ...
?php
class Animal {
// Constructor
function Animal() {
}
}
?
In PHP5 the method is now __construct(), thought the PHP4 behaviour
On 6/26/07, Richard Quadling [EMAIL PROTECTED] wrote:
The use of initialise / initialize for me is an issue purely from a
spelling perspective - both are acceptable spellings but only 1 would
actually be used. I would suggest 'construct' as the initialise
method.
We're keeping initialize
On 26/06/07, Mislav Marohnić [EMAIL PROTECTED] wrote:
On 6/26/07, Richard Quadling [EMAIL PROTECTED] wrote:
The use of initialise / initialize for me is an issue purely from a
spelling perspective - both are acceptable spellings but only 1 would
actually be used. I would suggest
On Jun 25, 7:50 am, Andrew Dupont [EMAIL PROTECTED] wrote:
On Jun 24, 7:48 pm, Tobie Langel [EMAIL PROTECTED] wrote:
I personally prefer the following syntax:
var Animal = new Class({
...
});
var Cat = new Class(Animal, {
...
});
I abhor this syntax. I wish I could put
On 6/25/07, Tobie Langel [EMAIL PROTECTED] wrote:
initialize is reserved, why not extends too - allowing the Class
constructor to automatically extend the new class by just looking at
the content of extends.
That's an interesting idea, Just rewrote below to better match the
rest of
Sorry, my OO is a bit slow.
I was sorta meaning like this, to take your current example
var Animal = new Class ({
initialize: function () { ... },
say: function () { alert('hi'); }
});
var Cow = new Class({
Extend: Animal,
Include: [Eatable, Breedable],
initialize: ..
say:
Is Base an option for the naming of the parent class?
Gareth
On 6/25/07, Kjell Bublitz [EMAIL PROTECTED] wrote:
Parent:
Please don't overuse the $ sign. It should be used for utilities and
nothing else. Don't mix it in other areas, such as classes.
Saying that, i still think it is good
Parent:
Please don't overuse the $ sign. It should be used for utilities and
nothing else. Don't mix it in other areas, such as classes.
Saying that, i still think it is good to introduce a parent property
.. To make it more convenient, name it parentClass. Easy to adopt
and no dollar.
Style:
I
Yes, keep it lower-case and add an s so it reads better :)
Cow-Class extends Animal (and) includes Eatable, Breadable ...
Remember that the idea is to distinguish them easily from instance
methods, hence capitalizing or prepending a $ sign.
On 6/25/07, Tobie Langel [EMAIL PROTECTED] wrote:
Yes, keep it lower-case and add an s so it reads better :)
Cow-Class extends Animal (and) includes Eatable, Breadable ...
Remember that the idea is to distinguish them easily from instance
methods, hence capitalizing or prepending a $
still a no-go for me. Classnames are capitialized, methods and vars
are lowercase. Its always been that way in all the common coding
guidlines ..
But if you insist, what about an underscore instead?
In JS that's usually implies that the property/method should be
considered as private, so I
On Jun 25, 4:41 am, Gareth Evans [EMAIL PROTECTED] wrote:
Is Base an option for the naming of the parent class?
I'd vote against it assiduously. It was my problem with Dean's
original naming as well. In a deep class structure (Organism Animal
Cat) it implies that the method being called is
On 6/25/07, Tobie Langel [EMAIL PROTECTED] wrote:
still a no-go for me. Classnames are capitialized, methods and vars
are lowercase. Its always been that way in all the common coding
guidlines ..
But if you insist, what about an underscore instead?
In JS that's usually implies that
I question whether new Class makes sense as an equivalent to
Class.create. The new keyword connotes an instance in JavaScript
-- with its own scope and method chain. Not all things being *created*
are instances.
That's a very valid point. It's unfotunately impossible to make a
constructor
Subclassing:
var Cat = Class.extend(Animal, instanceMethods, classMethods)
This is much smarter than Animal.extend(...) because you may wish to have
a class method named extend on your classes.
Agreed. though I think the Class.create({Extend: Animal, ... })
syntax suggested earlier is
On 6/25/07, Mislav Marohnić [EMAIL PROTECTED] wrote:
You can't achieve this in JavaScript. Simply let it go.
Word.
I like Mislav's approach to keep all the OOP functionality in Class.
Really don't want anything cluttering up the methods or properties of my
classes.
No real opinion on the name
On 6/25/07, Tobie Langel [EMAIL PROTECTED] wrote:
Class.include(Animal, Enumerable)
Class.alias(Animal, ...)
How do you handle precedende handled between mixin and instance
methods ?
Can you rephrase the question please?
- no dollar-signs and underscores because they indicate
I agree with everything Mislav said and would adopt that syntax in a
heartbeat.
My only concern is with the signature of Class.create and
Class.extend. I feel like having instance methods and class methods in
adjacent arguments can hurt the readability of the code. If you're
skimming a file you
I'm getting more and more convinced that extra magic such as classMethods
and aliasMethods are unnecessary. You guys are making some great points.
Keeping it simple is best.
+1 for sup() ... very low risk of naming conflict, and no ugly symbol (I
won't go a far as saying bad design, but it
On Jun 25, 11:29 am, Ken Snyder [EMAIL PROTECTED] wrote:
I'd also like to throw in the idea that we need to prove the final
OO-design decisions with use cases. We can write animal-sounds code all
day long, but JavaScript is such a unique language, I think we ought to
prove the design by
On 6/25/07, Andrew Dupont [EMAIL PROTECTED] wrote:
Perhaps someone could volunteer to convert a piece of Scriptaculous or
Rico just for illustration purposes?
Stuff in Prototype that benefits from inheritance:
TimedObserver, PeriodicalExecuter, Form.Observer, Form.Element.Observer,
Mislav Marohnic' wrote:
On 6/25/07, *Andrew Dupont* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Perhaps someone could volunteer to convert a piece of Scriptaculous or
Rico just for illustration purposes?
Stuff in Prototype that benefits from inheritance:
TimedObserver,
How do you handle precedende handledbetween mixin and instance
methods ?
Can you rephrase the question please?
Sure (there was a handled too many in there): do instance method
always have precende over mixins ones ? (from the API you suggest, I
suppose mixins are included *after* class
It's really topnotch.
I'm already use it ;-)
But what about the static methods and properties?
I would like to do something like this:
Employee = Class.extend(Person, {
initialize: function(name, dept) {
this.parent(name);
this.dept = dept;
},
toString: function() {
After getting rake to work ...
1) Makes sense: Yes, Surprised: No, seems like the next logical step,
Suggestion: see below
2) this.parent() .. the name parent is not tooo obvious tho, but i
couldn't think of a better one either. On first sight i thought you
mean this.parent() would refer
This is good stuff! I think the syntax is just about perfect, and even
though it doesn't involve inheritance, I *love* that I'll be able to pass a
hash of methods directly to Class.create() (or Class.extend()).
I'm perfectly happy using this.parent() since super is reserved. I can't
think of
I personally prefer the following syntax:
var Animal = new Class({
...
});
var Cat = new Class(Animal, {
...
});
Also, I think that this.sup or this.$super would be safer than using
this.parent, which, in the realm of DOM scripting might be used pretty
often inside classes already.
Slightly OT,
While you are looking at mooTools, you may want to look at their
custom Object events and
Ryan Johnson Object.Event: http://livepipe.net/projects/object_event/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
40 matches
Mail list logo
