Just a working idea, but instead of blindly using camelize on the key,
is there a way we can work out if it needs to be camelized in the
first place?
On Feb 19, 9:12 am, Thomas Fuchs <[EMAIL PROTECTED]> wrote:
> Nice, as always! :)
>
> Two issues:
>
> - Element.setOpacity should probably a "priva
Nice, as always! :)
Two issues:
- Element.setOpacity should probably a "private" method, as it
doesn't $() it's argument for non Gecko/non-IE browsers (different
behaviour), and we should require users to use setStyle
({opacity:blah}) anyway
- camelize() as discussed elsewhere (could be so
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
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
24 matches
Mail list logo
