Bemi Faison wrote:
> On Friday, September 2, 2011 5:02:26 AM UTC-7, Scott Sauyet wrote:
>
>> [ ... ] Can you also choose to have immutable
>> properties? I would expect area to be only an accessor not a
>> mutator. I can't quite buy the notion of an area function that allows
>> you to set the height and width. But that is a secondary concern.
>
> Yes, GSet lets you configure each method as a getter and/or setter.
>
> The .area() method you want would set the first (or "get-index") only, like
> so:
>
> var mySquareAccessor = new GSet(theScope,
> {
> area: [
> function () {
> return calcArea(this.width, this.length);
> }
> ]
> }
> );
> [ ... ]
This is clean and clear to me. It's too bad its performance doesn't
meet your criteria, because I do see a place for this sort of facade
over more complicated objects. I'm still not sure I would bother with
it for something like a Rectangle class, but perhaps it might be
usefule for an Ajax class that wrapped up the underlying XHR with a
clean interface, or for many complicated business objects.
I tend to write this sort of facade on an as-needed basis, but I can
certainly imagine wanting to use a library to make it easier.
>> I would expect some degradation from a naive prototype-based approach,
>> but does it degrade too much to be useful? At least for client-side
>> JS, I find that many significant performance optimizations in don't
>> noticeably affect the end user.
>
> The impact of deep-closures is negligible, numerically speaking, and
> subjective otherwise. Principally, however, closures do hurt application
> performance, especially when run on poor user-agents. Compared to native
> timings, GSet had unconscionably slow numbers (we're talking hundredths of a
> millisecond, of course)... I think there are five closures per method.
Again, though, we know that using wrappers like this (especially with
five closures per method!) will be substantially slower than their
native counterparts, but if this is for client-side scripting, the
only measures that really matter are those that affect the user. If a
clean technique makes the code much cleaner but it increases the time
of a user interaction from 57 ms to 59 ms, I'm almost always willing
to accept it. If it changes from 100 ms to 200 ms, it's most likely
unacceptable, because the user would clearly notice. Things are
entirely different in non-UI code of course. But for me usually the
issue is one of *perceived* performance.
That said, on my current project, a co-worker wrote a generic routine
to do a get on an object by dotted path notation,
(`myPerson.get("addresses.mailing.city")`), and while it was
convenient, it did turn out to cause noticeable performance
degradation and we had to remove it. In another part of the
application, we have a similar routine that does much the same with
somewhat different constraints, and it is now one of the biggest
performance bottlenecks. This one is more central to our
architecture, though, and we can't scrap it, so I'm in the middle of a
performance-oriented rewrite of it. I would never bother with this
though if it wasn't causing user-noticeable performance issues.
> While there is a place for libraries like GSet and XJSAccessors - until
> native solutions are widespread - there isn't any demand. That kind of
> low-level object configuration just isn't part of the JavaScript culture,
> yet.
I'm not sure I want it ever to become so, myself. One of the joys of
the language is in working with it as a fairly high-level language.
Dealing with this sort of configuration is much less interesting. I'm
hoping that it never becomes necessary.
>> P.S. Any recent news on your flow code? (I can't remember it's name
>> offhand.)
>
> Speaking of Flow, the current version uses GSet.
Oh, right it's also called "Flow". I should have remembered. :-)
> The next version is in
> development, and will not use GSet, for all the aforementioned reasons.
> However, I do provide some object protection by creatively using the
> prototype-chain - if I do say so myself. The result is a much smaller
> footprint, fewer closures, and faster performance. I'm busy nowadays, but
> will blog something decent in a month or so (don't hold your breath). In the
> meanwhile, you can preview the new code on github.
I will when I have a few additional minutes to breathe. :-)
-- Scott
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
