[Prototype-core] Re: On Class#create
I have indeed noticed that. I quite often use function without named arguments and then populate what I need from the arguments collection. I was wondering why was that so. I mean creating a class does not need infinite number of arguments, now would it? In the longest case scenario it needs class name (prototype creates differently but still), parent class, own fields / method, an array of mixins to borrow methods from. So in Prototype's case, that would be three arguments. Creating and instantiating a prototype class is notoriously slow. I was looking for ways (from my point of view) how the process could be a bit faster. And I say a bit, since notoriously slow means some ticks slower. On Nov 11, 12:44 pm, T.J. Crowder t...@crowdersoftware.com wrote: Class.create does have arguments, details in the docs[1]. The implementation doesn't use any _named_ arguments, it accesses its arguments via the `arguments` array (on the first line of the function, in fact). --~--~-~--~~~---~--~~ 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] On Class#create
I was wondering for the longest time why doesn't Class#create have
arguments?
I mean it's obviously to allow inheritance from multiple objects, but
honestly, how often does this happen?
S.. If arguments are provided, Class#create could look like
function create(parent, properties) {
if (typeof parent !== function) {
properties = parent;
parent = null;
}
... // more code
if (parent) {
subclass.prototype = parent.prototype;
klass.prototype = new subclass;
parent.subclasses.push(klass);
}
if (properties)
klass.addMethods(properties);
... // more code
}
which avoids few function calls. More over, if indeed multiple
inheritance is required it could be done in the addMethods method with
looking for special key (say implements or inheritsFrim or what ever).
However, typeof is kinda unfriendly looking to me. I don't know how
many of you are using MS Client JS, but they have an extra property
__typeName to indicate the type of object being worked with.
So if there was indeed such a mechanism in Prototype, the syntax would
become
if (!parent.__typeName || parent.__typeName != class)
It is indeed longer than the first one, but looks friendlier (to me)
and actually having an easy way to check whether or not an object is a
class seems handy (again to me).
Any thoughts?
--~--~-~--~~~---~--~~
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
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
On Oct 3, 5:24 pm, Robert Kieffer bro...@gmail.com wrote: Quick reality check: Where is the value in String/Array functions that test for emptiness? 'These methods are nothing more than wrappers around code like, if (!aString) ..., or if (!anArray.length) ... - i.e. JS already has perfectly good constructs for this. It's worth noting that (!aString) is more or less equal to (String.isUndefinedOrNullOrEmpty) than it is equal to (String.isEmpty). Also, since we have no type hinting, (!aString) will work easily with objects, strings, numbers, booleans and basically everything, where as (String.isEmpty), or any string method for that matter, should throw an argument exception when receiving different type of arguments. At the same time (!aString/anArray.length) are perfect examples of JS magic in use. But then, the logical question is why use (Object.isFunction) over (typeof object === function)? It seems that the more questions are asked about the core semantics of Prototype, more questions arise. On Oct 4, 10:30 am, T.J. Crowder t...@crowdersoftware.com wrote: I'm with Robert, is there a good use case for these or should we just deprecate them? Now that is and interesting question. To me, to using (aString == String.empty) over (aString == ) is all about the sugar. Never the less I agree that any JS library should be bloated with useless code. --~--~-~--~~~---~--~~ 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Suggestion: String#isEmpty instead String#empty
I've been pondering on this one for quite a long time -- why is it String#empty instead of String#isEmpty? To me String.empty should be a field equal / referencing the empty string and not a method. I was gonna hold this to my self, but the last few days there's been some discussion about semantics (Element#destroy and Function.empty per say) and I though may be it about time to ask this question. So is there any particular reason, besides #empty being shorter than #isEmpty and does my suggestion make sense to you? --~--~-~--~~~---~--~~ 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Suggestion: Prototype.Namespace or window.Namespace (Namespace creation function)
Currently Prototype lacks a namespace creation function.
I know, the function is quite simple, and I can write it my self
(which I have done), but do you think it will be nice to have one
built in Prototype?
The basics of the function is quite easy
function Namespace(identifier) {
var cursor = window;
if (identifier) {
var spaces = identifier.split(.);
for (var i = 0; i spaces.length; i++) {
if (!cursor[spaces[i]]) cursor[spaces[i]] = {};
cursor = cursor[spaces[i]];
}
}
}
Or if there is need to extend the namespace with classes
function Namespace(identifier) {
var cursor = window,
klasses = arguments[1] || false;
if (identifier) {
var spaces = identifier.split(.);
for (var i = 0; i spaces.length; i++) {
if (!cursor[spaces[i]]) cursor[spaces[i]] = {};
cursor = cursor[spaces[i]];
}
}
if (klasses) {
for (var klass in klasses) {
cursor[klass] = klasses[klass];
}
}
}
Noting fancy. I've seen far more complicated examples, which can do
tons more stuff. Sample usage would be:
Namespace(My.Name.Space);
My.Name.Space.MyClass = Class.create ...
In addition, I also set two additional fields to indicate that
My.Name.Space spaces are indeed namespaces (and not classes or fields)
as well as setting the name of each space. But this might be over-
doing for some, so it's not in the snippet.
Any thought on that one?
--~--~-~--~~~---~--~~
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
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Now that 1.6.1 is out and api.prototypejs.org is official...
Is it just me, or the usability of the new API micro site isn't as good as the old one? I mean before, if I wanted to know more about Event#observe, I would just type /api/element/observe, where as the new url would be api.prototypejs.org/dom/event.html#observe-class_method which happens to be way harder. Also, the old API micro site had dedicated page for each method, where as the new one has all methods in one page. May be I am too used the way the old site was organized. What do you think? -- joneff On Sep 2, 12:25 am, T.J. Crowder t...@crowdersoftware.com wrote: ...is there a plan for putting redirects or what-have-you in place from the old API locations? E.g.,http://prototypejs.org/api/element- http://api.prototypejs.org/dom/element.html? If redirects are possible in Mephisto, I could have a crack at it, but perhaps in the short term (since not all of the content has been moved over yet) it would be better just to have links at the top... -- T.J. --~--~-~--~~~---~--~~ 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Element#siblings
I poked around even more to see if there could be anythings improved.
I added tests for querySelectorAll, Xpath and native
nextSiblingElement (if present).
Alas, with qsa is quite tricky to simulate siblings -- I had to set
and unset attributes to achieve it and to use [] and :not selectors.
XPath has rules for siblings (preceding and following, but not all) --
fairly simple, but quite slow (why?).
While in FF 3.5.2 siblingsKangax rulles them all in Opera 9.5 and
Chromium Portable things tend to be different.
http://groups.google.com/group/prototype-core/web/element%23siblings%20%282%29.zip
On Sep 3, 4:47 pm, kangax kan...@gmail.com wrote:
`adHocSiblings` is clearly faster. I guess since it avoids 2 extra
function calls (`previousSiblings` and `nextSiblings`).
Running a simple test based on your example page:
var tdEl = document.getElementsByTagName('td')[100];
var t = new Date();
for (var i=1000; i--; ) protoSiblings(tdEl);
var t1 = new Date() - t;
t = new Date();
for (var i=1000; i--; ) adHocSiblings(tdEl);
var t2 = new Date() - t;
t = new Date();
for (var i=1000; i--; ) siblings2(tdEl);
var t3 = new Date() - t;
document.write(
'protoSiblings: ' + t1 + 'ms;br'+
'adHocSiblings: ' + t2 + 'ms;br'+
'siblings2: ' + t3 + 'ms');
where `siblings2` is practically your `adHocSiblings`, but with few
more optimizations (such as do-while instead of while-do, as well as
removal of `push` and `arguments`) -
function siblings2(element) {
if (!element) return [];
var originalElement = element, elements = [], i = 0;
element = element.parentNode.firstChild;
do {
if (element.nodeType == 1 element != originalElement) {
elements[i++] = element;
}
} while (element = element.nextSibling)
return elements;
}
=== FF 3.5.2
protoSiblings: 41ms;
adHocSiblings: 23ms;
siblings2: 19ms
=== Opera 10
protoSiblings: 78ms;
adHocSiblings: 61ms;
siblings2: 45ms
=== Safari 3.2.1
protoSiblings: 28ms;
adHocSiblings: 17ms;
siblings2: 14ms
--
kangax
On Sep 3, 5:33 am, Иван Жеков jon...@gmail.com wrote:
Actually I did make a test case
--http://groups.google.com/group/prototype-core/web/element%23siblings
zipped to take less space from the quota.
For fair tests, I extracted the methods as simple functions.
Note:
* The first click is noticably slower then the rest of the clicks.
* Actual exectution vary for me on every page refresh.
I get 5ms for the ad hoc method and 7 for the proto method.
2009/9/3 kangax kan...@gmail.com
On Sep 2, 6:25 pm, joneff jon...@gmail.com wrote:
(It's kinda long and it might be for the other prototype group, but I
am not sure.)
I was poking around with a script for manipulating tables which takes
heavy use of Element#siblings for some of the manips.
And I found that in some cases it [the method] tends to be slow. Not
slow like Vista on a 486 PC but slow as in a bit slower than I
expected.
But then again I am usually testing on 1000 row tables with enough
cols to make FF choke and was like maybe it's supposed to be like
that. maybe if I use querySelectorAll it will be faster.
I mean, I do remember an immediate following sibling selector (+) and
all following siblings selector (~). It seemed to me, that there
should be ALL siblings selector. Alas I was wrong. Not to mention it's
kinda wicked to work with qSA.
So what I did was to dig in prototype code and find the
Element#siblings. I admit it's logic is perfect -- ALL siblings = next
siblings + following siblings. The only thing that bothered me was the
amount of function calls -- I mean this function call that function,
and calls another one, and another one and so on and so forth.
Note: I am do CSS for a living. Thus I have absolutely no idea how
much time it takes (if any) to jump from a function to function.
Anyway, I made my way up the function, trying to keep the code general
feeling and I was left with this
siblngs: function (element) {
if (!element) return [];
element = element.parentNode.firstChild, elements = [];
while (element) {
if (element.nodeType == 1 element != arguments[0])
elements.push
(Element.extend(element));
element = element.nextSibling;
}
return elements;
}
which, I have to admit wasn't as faster as I expected.
Anyway, I went over to jQ and mT to see how they do it.
jQ's approach was more or less similar. It does use this weird for
statement (translated to fit) -- (;element;element.nextSibling) --
instead of the while, but the I guess that wouldn't make a difference.
mT was even more exotic then the original Prototype method, but kinda
has the same spirit as the one above.
Sooo... Like I noticed in the beginning, that was long, and I am still
not sure it's
