[Prototype-core] Re: Inheritance: your thoughts?
> I abhor this syntax. I wish I could put it any more mildly.
Haha! Actually, I'm quite fond of it, but I can see how it could be
misleading.
> I hesitate to do this because of the burden of backwards
> compatibility. Any static method called "extend" would simply stop
> working. We can't break code that's worked in every version of
> Prototype since 1.0. (You could also make this argument about
> "parent," but my gut feeling is that "extend" is a far more common
> name for a method.)
Although I don't particularly like this notation, I think we could
code around backward compatibility issues by special casing
Class.create not add the class method "extend" if it's called without
any arguments.
> I also like the fact that Class.extend and Class.mixin would mirror
> the existing Object.extend and a proposed Object.mixin (which would
> work the same way as Object.extend, but wouldn't overwrite already-
> defined properties on the destination object). Of course, Tobie seems
> to *hate* this, so we've got some stuff to sort out. :)
Just to clarify: I don't hate it, I just think that if the only thing
it does is obfuscate the fact that we are using prototypish
inheritance it's not woth adding them. i.e. if Class.mixin is nothing
more than Object.mixin(target.prototype, source).
I more in favor of being able to add mixins during class creation (via
a *magic* property name) and be sure that they don't overwrite
instance methods.
Idealy, this would mimick ruby implementation, where you can still
access the mixin's method using this.$super (the implementation I
posted a while ago did that).
To summarize:
I would like to have the following magic properties:
- ClassMethods (or $Class, $ClassMethods, $class)
- Include (or $Include $Mixin or $include)
- Alias (or $Alias, $alias)
Access parent instance methods or shadowed mixin's with this.$super
(or this.sup or this.uber, but not this.parent)
Have it consistent: i.e. either we use $ everywhere or we don't.
For example creating a new "Cow" class whose parent is "Animal":
var Cow = new Class(Animal, { // or Class.create(Animal, {...
ClassMethods: {
count: 0,
},
Include: [Eatable, Breedable], // these are mixins
initialize: function(age, owner) {
this.sup('cow', age, owner);
},
talk: function() {
return 'meuuuh';
},
eat: function(food) {
// eat food
},
Alias: {
talk: ['say', 'speak'],
eat: 'feed'
}
});
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
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 it any more mildly.
In languages with class-based inheritance, class creation and class
instantiation are two separate concepts. Defining a class is done
within a control structure. I can think of nothing more confusing than
instantiating Class to create your class, then instantiating your
class to create an instance of the class you just instantiated with
Class.
> 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.
"this.$super" is fine with me, but every time I see "this.sup" I think
of this. [1]
On Jun 24, 7:36 pm, "Adam McCrea" <[EMAIL PROTECTED]> wrote:
> My thoughts on the "magic": If the implementation of Class.inherit() didn't
> depend on the "subclasses" property, I would say it is too much magic. I
> just can't think of a situation where I would need it. However, I see that
> the implementation requires it, and it really doesn't bother me. I don't
> think there is enough risk of naming conflict to necessitate a prefix.
This is what I wonder, though: if there's no value to the developer,
why expose it at all? I think if it's for internal use it ought to
have some sort of prefix.
> The only feature request I have is for a convenient way to alias methods.
> Object.extend() does okay for this, but I'd rather keep it in the class
> definition. Something like this:
>
> var Cat = Class.create({
> talk : function() { return "meow" },
> aliasMethods : {
> speak : "talk",
> saySomething : "talk"
> }
>
> }
A good example of the sort of "magic" I was talking about.
We've talked about doing things like this -- treating certain property
names within the object literal as special. In the spirit of Miha's
example:
var Cat = Class.create({
talk: function() { return "meow"; },
$ClassMethods: {
cleanLitterBox: function() { /* ... */ }
}
});
In this example we use a special keyword to mark class (static)
methods -- so that we don't have to Object.extend them at a later
time. I could go either way on this issue. But I think that if we have
any magical properties, they should all have some sort of prefix by
convention (like $) *both* to minimize naming collisions *and* so that
they can be recognized as "magical" at a glance.
> Quick question on the "superclass" property: For the negative test on line
> 320, should the superclass is referenced using
> pet.constructor.superclass rather than
> pet.superclass?
Probably. Good catch.
On Jun 24, 9:01 pm, jdalton <[EMAIL PROTECTED]> wrote:
> Have you all looked at how mootools does it:
> I really like how they add 'extend' and 'impliment' as part of the
> native new class methods.
I hesitate to do this because of the burden of backwards
compatibility. Any static method called "extend" would simply stop
working. We can't break code that's worked in every version of
Prototype since 1.0. (You could also make this argument about
"parent," but my gut feeling is that "extend" is a far more common
name for a method.)
I also like the fact that Class.extend and Class.mixin would mirror
the existing Object.extend and a proposed Object.mixin (which would
work the same way as Object.extend, but wouldn't overwrite already-
defined properties on the destination object). Of course, Tobie seems
to *hate* this, so we've got some stuff to sort out. :)
Cheers,
Andrew
[1] http://www.geocities.com/ratscabiesholygrail/supcat.jpg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Template Class (documentation related)
It's got nothing to do with luck. Arrays are implemented as a very light veneer on top of Objects; the only real difference between them is the literal syntax ([]) and the magic "length" property that counts your numeric keys. (In fact, the numeric keys aren't really numbers, since all object properties are coerced into strings.) Considering that the Selector class uses Template strings with arrays, I wouldn't call it improper, either. We can argue about whether it's "hacky" or not, but it's a behavior that deserves to be documented. Thanks for bringing this up, Jon; I'll put this on our documentation to-do list. Cheers, Andrew On Jun 24, 9:36 pm, jdalton <[EMAIL PROTECTED]> wrote: > I find using the object is easier to read, also looking at the source > its really meant for objects to be used, you got lucky in that > object['days'] is also the same syntax used by array[0]. That is why > indexes would work for your array and not for the object and why the > property 'days' would work for the object and not the array. > > I don't think the documentation should support improper usage. I would > classify using an array instead of an object as hacky implementation. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Template Class (documentation related)
I find using the object is easier to read, also looking at the source its really meant for objects to be used, you got lucky in that object['days'] is also the same syntax used by array[0]. That is why indexes would work for your array and not for the object and why the property 'days' would work for the object and not the array. I don't think the documentation should support improper usage. I would classify using an array instead of an object as hacky implementation. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
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 Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
I dig Class.extend()
It's keeping consistent with how things are done now.
I am mixed about "parent". I have used a property of 'parent' in some
of my old code, but not as a method.
Also PHP uses parent::methodName() so I can see how one would think to
use it.
I don't like using $ to prefix parent.
Have you all looked at how mooTtools does it:
I really like how they add 'extend' and 'impliment' as part of the
native new class methods.
http://docs.mootools.net/Class/Class.js
var Animal = new Class({
initialize: function(age){
this.age = age;
}
});
var Cat = Animal.extend({
initialize: function(name, age){
this.parent(age); //will call the previous initialize;
this.name = name;
}
});
var myCat = new Cat('Micia', 20);
alert(myCat.name); //alerts 'Micia'
alert(myCat.age); //alerts 20
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
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.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
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 anything better, and I definitely wouldn't want it cluttered with a
"$" prefix.
My thoughts on the "magic": If the implementation of Class.inherit() didn't
depend on the "subclasses" property, I would say it is too much magic. I
just can't think of a situation where I would need it. However, I see that
the implementation requires it, and it really doesn't bother me. I don't
think there is enough risk of naming conflict to necessitate a prefix.
The only feature request I have is for a convenient way to alias methods.
Object.extend() does okay for this, but I'd rather keep it in the class
definition. Something like this:
var Cat = Class.create({
talk : function() { return "meow" },
aliasMethods : {
speak : "talk",
saySomething : "talk"
}
}
If there is any interest, I'd be happy to write up a patch for it.
Quick question on the "superclass" property: For the negative test on line
320, should the superclass is referenced using
pet.constructor.superclassrather than
pet.superclass?
- Adam
On 6/23/07, Andrew Dupont <[EMAIL PROTECTED]> wrote:
>
>
> We've been working on a more robust class-based inheritance model,
> fashioned after Dean Edwards's Base and others like it. There's an
> inheritance branch in the SVN repository that shows our latest
> efforts.
>
> We've had some lively internal discussions about syntax. I figured I'd
> hold my finger to the wind and see how the list feels about some of
> these issues.
>
> First, go to < http://dev.rubyonrails.org/browser/spinoffs/prototype/
> branches/inheritance/test/unit/base.html> and take a look at the
> handful of unit tests we've written for inheritance. The fixtures
> start at line 60 (Animal, Cat, Mouse) and the tests start at line 315.
>
> Next, consider these questions:
>
> 1. Does the current API make sense? Was there anything about it that
> surprised you? Anything you'd add or remove?
> 2. Does "this.parent()" make sense as a way of calling the
> superclass's method? (We can't use the word "super" because it's
> reserved in JavaScript).
> 3. Right now there are a few "magic" properties in class instances:
> "superclass," "subclasses," and "parent." Is this too much magic? Not
> enough magic? Do you think these are likely enough to conflict with
> existing properties of a class that it's worth namespacing them
> somehow? ($superclass, $subclasses, $parent, etc.)
>
> Feel free to make feature requests or ask other questions. Kudos to
> Alex Arnell's inheritance scheme inheritance/> for getting all of this started.
>
> Cheers,
> Andrew
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
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 to parent Object and not parent method
of the same name.
3) I couldn't find the magic properties you wrote about, but i would
like to have them and think that the amount of magic is just about
right.
While writing this mail and going on about your questions, i had a
hard time to find something i could suggest.. i think the
implementation is perfect so far
Maybe it would be great to have a parent property to access all -
original- superclass methods and properties:
var TomCat = Class.extend(Cat, {
initialize: function() { this.name = "Tom"; },
hunt: function() { return this.say('hunting Jerry'); }
});
var JimCat = Class.extend(TomCat, { // note: Sub of TomCat
initialize: function() { this.name = "Jim"; },
hunt: function() { return this.say('hunting Tom'); }
});
t = new TomCat();
j = new JimCat();
t.hunt() // -> Tom: hunting Jerry
j.hunt() // -> Jim: hunting Tom
j.parent.hunt() // -> Tom: hunting Jerry
j.parent should contain the superclass as it is. It would allow more
flexibility, i think, while calling "return this.parent()" in
JimCat::hunt() stays as it is and results in "Jim: hunting Jerry".
What do you think about it?
Best,
Kjell
Am 23.06.2007 um 22:02 schrieb Andrew Dupont:
>
> We've been working on a more robust class-based inheritance model,
> fashioned after Dean Edwards's Base and others like it. There's an
> inheritance branch in the SVN repository that shows our latest
> efforts.
>
> We've had some lively internal discussions about syntax. I figured I'd
> hold my finger to the wind and see how the list feels about some of
> these issues.
>
> First, go to branches/inheritance/test/unit/base.html> and take a look at the
> handful of unit tests we've written for inheritance. The fixtures
> start at line 60 (Animal, Cat, Mouse) and the tests start at line 315.
>
> Next, consider these questions:
>
> 1. Does the current API make sense? Was there anything about it that
> surprised you? Anything you'd add or remove?
> 2. Does "this.parent()" make sense as a way of calling the
> superclass's method? (We can't use the word "super" because it's
> reserved in JavaScript).
> 3. Right now there are a few "magic" properties in class instances:
> "superclass," "subclasses," and "parent." Is this too much magic? Not
> enough magic? Do you think these are likely enough to conflict with
> existing properties of a class that it's worth namespacing them
> somehow? ($superclass, $subclasses, $parent, etc.)
>
> Feel free to make feature requests or ask other questions. Kudos to
> Alex Arnell's inheritance scheme inheritance/> for getting all of this started.
>
> Cheers,
> Andrew
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
As advised here: http://www.w3.org/TR/html401/types.html#type-name "ID and NAME tokens must begin with a letter ([A-Za-z]) [...]" Which clearly implies that ids cannot be number only. On Jun 24, 1:25 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I'd like to add a bit of OT to the discussion, but relating to the $ > function itself. > > Currently, $ wil not return an element, whose id is a number, whereas > getElementById will. > > The fix, as you can imagine, is pretty simple. > I myself just changed the following line: > > if (typeof element == 'string') > > to: > > if (typeof element == 'string' || typeof element == 'number') > > I don't know if this is the most optimized way though. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On 6/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Currently, $ wil not return an element, whose id is a number, whereas > getElementById will. A number is an illegal ID value. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
I'd like to add a bit of OT to the discussion, but relating to the $ function itself. Currently, $ wil not return an element, whose id is a number, whereas getElementById will. The fix, as you can imagine, is pretty simple. I myself just changed the following line: if (typeof element == 'string') to: if (typeof element == 'string' || typeof element == 'number') I don't know if this is the most optimized way though. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Inheritance: your thoughts?
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() {
return this.parent() + " works in " + this.dept;
},
static: {
methodName: function() {
// ...
}
}
});
var joe = new Employee("Joe", "Sales");
Employee.methodName(...);
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: strip method of String class.
On 6/24/07, Christophe Porteneuve <[EMAIL PROTECTED]> wrote: > > > Really? I had benchmarked the single-regex one on FF1.5 and FF2 and it > *was* much faster on large string sets (not necessarily large strings). > However, lemme guess... Safari b0rks? ;-) http://dev.rubyonrails.org/ticket/4182#comment:2 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
