On Friday, October 22, 2010, Andreas Hocevar <ahoce...@opengeo.org> wrote: > > On Oct 22, 2010, at 07:27 , Eric Lemoine wrote: > >> On Thursday, October 21, 2010, <christopher.schm...@nokia.com> wrote: >>> >>> On Oct 21, 2010, at 4:45 PM, ext Xavier Mamano (jorix) wrote: >>> Good appreciation Andreas, now Chome is still the best but it's not a >>>> >>>> miracle :-) >>> >>> >>> Er, not to be too critical here or anything, but it does look like >>> Safari beats Chrome in every case except the one we're trying to >>> discuss throwing away :) >> >> Jorix's number also show that "Object Litteral" doesn't lead to >> significantly better performance than "Pure JavaScript", which makes >> me think making this change in the lib is really worth it. > > The advantage of object literals is that it's straight forward.
I think going from "OpenLayers.Class" to "Pure JS Type" is even more straight forward—no refactoring would be needed as method calls on objects will continue to work. > We do have OpenLayers.Class, which gives us many advantages (like instanceof > checking). Having instanceof work is a must-have. And using "Pure JS Type", as I proposed, would't break that. > So instead of introducing a new hybrid with an inherit function (remember: we > got rid of one 3 years ago), This is a different situation. Previously we have OpenLayers.Class for creating base classes and OpenLayers.Class.inherit for creating subclasses. We simplified this in such a way that OpenLayers.Class can be used to define both base classes and subclasses. I'm proposing to simplify even more, by using pure JS types for defining base classes and a simple, minimal "extend" function for defining subclasses. So, to me, this isn't going back, but moving forward. > I'd say two things are in order: > > * Revisit OpenLayers.Class. Obviously there is room for improvement in there. If we want to avoid the initialize.apply calls, which cost, "Pure JS Types" for base classes is the way to go. > * Allow the use of object literals wherever possible. I think we should first remove OpenLayers.Class, which wilm yield performance improvements. And once done, we can use object litterals where it makes sense. > The latter really isn't that much effort. For example, wherever we want to > show the user a string representation of a pixel, we currently would do: > > alert(pixel.toString()); > > If we accept an instance of OpenLayers.Pixel or an object literal, we can > safely do > > alert(OpenLayers.Pixel.prototype.toString.call(pixel); > > No need to distinguish between an OpenLayers.Pixel instance and an object > literal. Yes. That being said, we create lots of Bounds when panning the map, and using object litterals for Bounds isn't as straight forward because of the containsBounds method and friends we apply. And again, using "Pure JS Types" gives us good performance, even better performance than object litterals in some browsers. > > And speaking of room for other performance improvements: we often create > clones internally where we would not need to. This is also very expensive. Definitely. And it's expensive because we do initialize.apply currently. I wouldn't be as expensive if using "Pure JS Types". Cheers, -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.com _______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev
