[Prototype-core] Re: Function.EMPTY and Function.K

2009-10-16 Thread Иван Жеков
Don't get me wrong, but we are not talking about splitting the core of the
atom in 16 different particles. Instead the topic of discussion is how to
name (and where to place) the empty and identity function.

Two things should be taken into account -- common sense and consistency.

Deriving from mathematics, how is this function called -- f(x) = x, for
every instance of x? Identity function. That's a the perfect name (as
mentioned above).

And since this is not a constant function, no need to be capitalized. And
since JS is generally camel case, first letter stays lowercase.

The place to put it? The Function object. Hence, Function#identity

Now apply the consistency and you get Function#empty

Simple as that.


Or use purely statistical approach:

If anyone bothered to sum up this elaborate discussion the result would be:

1) Prototype#emptyFunction and Prototype#K are considered / approved / you
name it for deprecation by the majority of people who post here

2) Function#empty (and caps) and Function#identity (and caps) are considered
/ approved / you name it for addition by the majority of the people who post
here.

Logical outcome -- if the core developers haven't decided yet whether or not
to use caps, make a poll (if you feel like to it), or use any random way to
determine the value of a boolean (0 for small caps, 1 for caps) -- get
wasted, ask a stranger, wait for 2012.

My apologies if I am rude in my words, but it's either commons sense, or
toss a coin (observe the moon phase etc).

*** A bit off topic ***

The real issue to me is consistency. While many of you noted that Prototype
was born of adapting ruby-like syntax for Java Script, I prefer it because
it's much closer to actual programming than some JS libraries and is not as
complicated as other libraries.

However, due to incompatibility of syntax between ruby and JS (string#empty?
per say) changes in the core (Language extension part) must made. The best
place to look for inspiration would be other ECMA standardized languages /
dialect, such as Action Script (the closes dialect to JavaScript there is)
or C# (not so close, but still in the vicinity of close syntax).

*** End of off topic ***

Again, two key components -- consistency and common sense.

May the Force.prototype extends you.

-- joneff

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

2009-09-03 Thread Иван Жеков
Actually I did make a test case --
http://groups.google.com/group/prototype-core/web/element%23siblings.zip --
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 for this group, and I having in mind I do CSS for a
  living, I am asking -- is this improved Element#siblings faster?

 Why not make a simple test case to see if it really is faster?

 --
 kangax
 


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