> Believe me, I see and understand precisely what you mean. No, I can't > come up with a real-world example. Does that mean that just because we > can't think of any positive use for synchronous calls that we should > explicitly disable a functioning portion of the browser's API? I > understand that an abstraction layer like Jabsorb is *supposed* to > shield developers from underlying API's, but this one seems a little > arbitrary. >
I understand what you are saying and I once did feel the same. But having programmed with async calls for a while it really does make perfect sense and there really isn't a need to do otherwise. > > I still think that using the object synchronously might have its place, > even in future development (the FAQ seems to agree with me, saying "You > should /almost/ never use synchronous calls"), but I also fully agree > that all developers should carefully consider why they're using it. > > If there's a way to make it harder to use but still accessible, that > would be the best of both worlds. Then the "hard way" could be > documented as a FAQ (extending FAQ #1), along with a primer on common > callback patterns. > Well, my option to do only do async code in the main library and to overload these methods in another optional javascript file that doesn't have to be included will solve this. The user doesn't generally have to worry about having the extra code in that does the sync calls and if they really want to be naughty they can. It shouldn't be too hard to implement this. > > BTW: I just wanted to say "Thanks" to you guys. This has been a civil > discourse; most of the time things like this aren't! > > We want more people talking, not less! We aren't going to alienate you for having a different opinion! Cheers, Will
_______________________________________________ Jabsorb-dev mailing list [email protected] http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev
