> 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" or "Class.open", but method names could be debated until everyone is blue in the face. There is only one improvement that I would really love to see added to the current inheritance branch. I just submitted a patch to my original inheritance ticket from just over a year ago. Patch URL (apply against latest inheritance branch revision): http://dev.rubyonrails.org/attachment/ticket/5459/block-notation.diff This patch lets a user optionally define a class inside a closure instead of a methods hash. Class definition inside a closure allows for some really interesting code, some of which I've outlined in a usage patterns pastie to save on message length. Usage Pastie URL: http://pastie.textmate.org/77884 > 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). Again, I think we could be here for months debating back and forth over method names. Having said that here is my two cents worth regarding this question. "this.parent()" was something I picked really quickly when I wrote the original inheritance patch. Of all the other options that have been presented, I am leaning towards "this.$super()" the most. I do agree it breaks the traditional Prototype convention of using $ for utility functions and it is not exactly that pretty, but there are a few pros to using a $ prefix here. 1. It stands out, and thus gains some special meaning, just like a $ utility method itself. 2. It is less likely to clash with any methods people are trying to define themselves. > 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.) I say leave the "superclass" and "subclasses" properties there for completeness, but don't bother adding tons of reflexion API style functions and/or helpers to access them. I don't believe there is no need to namespace them either, if people are using properties of the same name they are most likely trying to implement some sort of relexion API code themselves. In which case, they should just write their reflexion API helpers to use the built in properties. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
