Just a quick question, why are you comparing against the string
'undefined', undefined is its own type and can be explicity tested
against, this saves casting it from one type to another. The same for
the if statement, doing an explicit match === for float detection, it
cant be anything other than
Marius Feraru a écrit :
> Ken Snyder wrote:
>>> And :empty seems tricky in XPath too.
> .//*[not(text())] should do the trick, but don't mind me, I'm already
> ound asleep (:|
It's good, if it *were* CSS3's definition of empty. CSS3 def of empty
requires no child element, nor non-empty chil
Andrew Dupont a écrit :
> On Feb 18, 9:45 pm, Ken Snyder <[EMAIL PROTECTED]> wrote:
>> Yes, it was very slow for me too with any of the "nth-" predicates.
>> That nth routine relies on counting the number of previous siblings FOR
>> EVERY NODE. I'm not sure if that is avoidable, but I've added
Ken Snyder a écrit :
> Yes, it was very slow for me too with any of the "nth-" predicates.
> That nth routine relies on counting the number of previous siblings FOR
> EVERY NODE. I'm not sure if that is avoidable, but I've added the
Yeah, you're O(n²) on this, and I think I found a way to be
Hi all,
I find myself writing code like that the whole time:
example = example === undefined ? null : example;
We could imagine the following utility function:
$default = function(value, default) {
return value === undefined ? default : value;
}
So that the above could be sh
Gentlemen, based on your progress I've managed to implement some more
stuff. I've updated patch #7568.
Supported are nearly all of the argumentless pseudoclasses, which I
consolidated into one regex. (Also implemented the general sibling
combinator: "div ~ p".) I haven't done exhaustive testing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ken Snyder wrote:
> And :empty seems tricky in XPath too.
.//*[not(text())] should do the trick, but don't mind me, I'm already
ound asleep (:|
- --
Marius Feraru
-BEGIN PGP SIGNATURE-
iD8DBQFF2SZgtZHp/AYZiNkRAlqYAKCP3rB8Ahn11th1YHWRweE
On Feb 18, 9:45 pm, Ken Snyder <[EMAIL PROTECTED]> wrote:
> Yes, it was very slow for me too with any of the "nth-" predicates.
> That nth routine relies on counting the number of previous siblings FOR
> EVERY NODE. I'm not sure if that is avoidable, but I've added the
> corresponding xpath...
Christophe Porteneuve wrote:
> ...
> Thanks for the code. I'm myself working on implementing PC's, and
> looking at your work is a boon. I like the general code architecture
> you did (how work gets split around nthFind, etc.), yet I need to do
> more careful inspection on it to verify that rege
Andrew Dupont wrote:
> ...
> I just submitted #7585: http://dev.rubyonrails.org/ticket/7585
>
> This patch also serves as an example of how I'd like to overhaul
> Prototype's browser detection.
>
This looks beautiful. Great work!
--~--~-~--~~~---~--~~
You recei
On Feb 18, 6:50 pm, "Martin Ellis" <[EMAIL PROTECTED]> wrote:
> Anyway we're straying massivly from the topic. The point goes back to
> the setStyle being a resource hog.
>
> How can this be improved as with the heavy dependance of it in
> script.aculo.us it is in desperate need of reworking.
I j
The purpose of JS2 is to open the way for more classical OO trained
programmers to use javascript, javascript is such a break from the
'norm' that its difficult for people who are expecting classes to
create elegant and maintainable code.
The hope is to maintain the prototypal abilties of javascr
Am 18.02.2007 um 22:07 schrieb Martin Ellis:
>
> "Also remember that less code means less possible breakage..."
>
> the memory leak with morph, this was caused by "less code".
IMHO, that was caused by a misbehavin' JavaScript engine... :)
--~--~-~--~~~---~--~~
Yo
On Feb 18, 3:29 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> Unfortunately, this is where JavaScript 2 is going right now. And it's
> already too late to change anything.
It's really not as bleak as all that. Most of what JS2 borrows from
Java is syntax. And if you don't care for type annot
On 2/18/07, Martin Ellis <[EMAIL PROTECTED]> wrote:
>
>
> Can't prototype.js be elegant without it looking like ruby code?
Prototype.js is not making Ruby in JavaScript. It just embraces the
conventions (modules, names, return types) because the two languages have
similar dynamic features. As for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Ellis wrote:
> The main problem is with the use of name.camelize() in the final call to
> element.style[] = value; Without the camelization of the name everything
> works must faster.
Is it really camelize() who imposes so much penalty? Event w
On Feb 18, 3:05 pm, "Martin Ellis" <[EMAIL PROTECTED]> wrote:
> Why cant prototype have elegant code and optimised code. I'm not
> talking about milliseconds of optimisation, even i am not that
> machocistic.
>
> But when a function gets so much use like setStyle, should
> asthetically pleasing co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sam Stephenson wrote:
> It's absolutely not about how long it takes to download the JavaScript
> file.
> "Less code" is a side effect of the desire to stay DRY, and means
> fewer opportunities for something to go wrong.
Sweet, I like keeping myself dr
"Also remember that less code means less possible breakage..."
the memory leak with morph, this was caused by "less code".
On Feb 18, 8:45 pm, Thomas Fuchs <[EMAIL PROTECTED]> wrote:
> Am 18.02.2007 um 21:24 schrieb Marius Feraru:
>
> >> Any optimization must preserve code readability and beau
Why cant prototype have elegant code and optimised code. I'm not
talking about milliseconds of optimisation, even i am not that
machocistic.
But when a function gets so much use like setStyle, should
asthetically pleasing code give way to optimisations to save seconds
or even minutes.
Code can st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Fuchs wrote:
> I'm pretty sure that's not the case with the majority of users.
Pitifully, they are clueless. :(
They are not able to distinguish between "load" and "run", nor about
"resource caching".
> Anyway, we don't really strive for downl
On Feb 18, 2:24 pm, Marius Feraru <[EMAIL PROTECTED]> wrote:
> Nicely said, with one possible amendment: "compactness" as in "code size"?
> I'd give that the lowest priority, "execution speed" IMHO is far more
> important than "download speed". After all, we're talking about "web
> applications",
Am 18.02.2007 um 21:24 schrieb Marius Feraru:
>> Any optimization must preserve code readability and beauty (think
>> maintainability) and compactness of the framework.
> Nicely said, with one possible amendment: "compactness" as in "code
> size"?
> I'd give that the lowest priority, "executio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mislav Marohnić wrote:
> Optimizing getStyle and setStyle methods would not be premature, but a
> very welcome optimization at this point. But it will not be easy. I tried
> to do it in #6696 and Marius took a different approach in #6705 (w/
> benchma
On Feb 18, 2:01 pm, Marius Feraru <[EMAIL PROTECTED]> wrote:
> Exactly. I'm on your side and I guess many more are using their own
> Prototype tweaks. Just keep your development bench up-to-date (synchronized
> with the current trunk [1]), update your tweaks and, whenever you think you
> found som
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Ellis wrote:
> However i need better performance that prototype can offer so i've been
> forced to fork the library and improve it myself to get the speed gains i
> require. I'm just trying to post my speed improvements here.
Exactly. I'm on yo
On Feb 18, 12:22 pm, Marius Feraru <[EMAIL PROTECTED]> wrote:
> So, the only issue still standing in this paragraph is "how to detect
> different versions". People [1] think the right choice is not "browser
> detection", but "object detection". This is a very weary subject, I don't
> really want t
The main problem is with the use of name.camelize() in the final call
to element.style[] = value;
Without the camelization of the name everything works must faster.
I personally always camelize the values in the object i pass to
setStyle before hand, instead of having the key as a string.
Maybe
On 2/18/07, Martin Ellis <[EMAIL PROTECTED]> wrote:
>
>
> I fully understand the argument for premature optimisation. But for me
> it, its late optimisation, really i needed the performance out of the
> box.
Optimizing getStyle and setStyle methods would not be premature, but a very
welcome optim
Sorry, my gmail was screwing up the groups nature of the thread and i
was getting confused.
I enjoy using prototype.js i find it very nice how it fluidly
integrates with the core parts of javascript.
However i need better performance that prototype can offer so i've
been forced to fork the libra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> I posted this in the spinoffs group as until 5 minutes i go i did'nt know
> this existed. a FYI on the prototypejs.org website the mailing list url
> points there, not here.
>
> Please read this:
> http://groups.google.c
Hey Ken,
Ken Snyder a écrit :
> :not(s)
> :first
> :last
> :first-child
> :last-child
> :empty
> :nth-child(n)
> :nth-last-child(n)
> :nth-of-type(n)
> :nth-last-of-type(n)
> :lang
Thanks for the code. I'm myself working on implementing PC's, and
looking at your work is a boon. I like the gene
I agree that Toggle should be removed, i have been spending alot of
time optimising the prototype library for my own projects, such as
removing bad and inefficient uses of functions and removing Toggle was
one of the first things i did.
One thing i would like to mention is that prototype is not s
I posted this in the spinoffs group as until 5 minutes i go i did'nt
know this existed. a FYI on the prototypejs.org website the mailing
list url points there, not here.
Please read this:
http://groups.google.com/group/rubyonrails-spinoffs/t/2c64e213e3d0f0df?hl=en
and possibly comment if you th
34 matches
Mail list logo
