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
-~----------~----~----~----~------~----~------~--~---
