SproutCore--over 20000 lines of new code!
in [JavaScript]
|
From: Garrett Smith on 12 Jan 2010 02:32 Ross Boucher wrote: > On Jan 11, 8:49 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> The similarities between Sproutcore include influence from Cocoa, >> compiling javascript, and variables such as: >> >> var YES = true, >> No = false, >> etc. >> > > The YES, NO issue isn't worth much discussion. I think the YES and NO variables are useless. Useless code should be removed. It is there to make > people coming from a Cocoa background more comfortable. Are Cocoa developers finding `true` to be too difficult to understand? I can't speak > for the Sproutcore team, but Objective-J is a programming language, > and one of the design goals of that language is compatibility with > Objective-C, so there's no reason not to have similar constants. The I disagree. There are reasons to not have similar constants. They are a waste of space and reduce efficiency. They take more time to resolve than a primitive value. Cocoa developers who are new to javascript will likely have false expectations, preconceptions, and misconceptions about javascript. The best way to get rid of those misconceptions is to learn the language. Providing a layer that makes the javascript look like Cocoa might seem appealing to Cocoa developers, but it really isn't helping them learn javascript. Then again, anyone having trouble understanding `true` and `false` is probably not worth catering too. > arguments against it are stylistic and subjective, but most > importantly it's a completely inconsequential part of both frameworks. It is not completely inconsequential. You have added global YES and NO variables. Every time one of those identifiers is used, it must be resolved all the way up the scope chain. The value is then obtained and used in the context where the identifier appears. In contrast, a boolean primitive `true` will not need to be resolved up the scope chain. A boolean primitive value will be interpreted immediately. The result is going to be slower performance for the identifier. Some implementations may perform tracing and/or upvar optimizations, but that is not something that is standard or should be expected; you shouldn't expect anything more than what the specification defines. Literal `true` should not be confusing for anyone; not even for non-programmers. `YES` and `NO` are useless. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 13 Jan 2010 00:21 On Jan 9, 3:11 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Thomas 'PointedEars' Lahn wrote: > > David Mark wrote: > > >> Thomas 'PointedEars' Lahn wrote: > >>> David Mark wrote: > >>>> Thomas 'PointedEars' Lahn wrote: > >>>>> Please do everyone a favor and, as your New Year's > >>>>> resolution, do not waste more bandwidth like this again. > >>>> No, I'm sorry, To hell with the bandwidth. > >>> And to hell with your readers? So you are just a poser after all? > >> As I said, that was pretty much a code dump, not a review. And don't > >> you worry about my readers as I am about to launch a site that > >> summarizes all of this stuff in one easy to find place (and that place > > > We (I think I can speak for all subscribers regarding this) do not need > > *such* "code dumps" here, thank you very much. > > >>> If you do not want to post so that it can be easily read, you are much > >>> better off with writing a diary. > >> So you feel my voice isn't being heard? :) > > > That is beside the point. Your voice would certainly be heard better and > > more clear if you would come to your senses and post something better > > readable than this. > > Good reviews take time. I can try and take a partial review: > > Looking at the datastore: > > http://github.com/sproutit/sproutcore/blob/master/frameworks/datastor... > > That depends on SC.Object.extend, defined here:- > > http://github.com/sproutit/sproutcore/blob/master/frameworks/runtime/... > > It is well-commented, I'll give it that. > > I'm not accustomed to where everything is defined and don't find it all > right away (the packaging is not intuitive). It is hard to follow method > calls across several files and it is unclear which file the method is > defined in. Things are added to Function.prototype in various places, > but it is uncertain where. > > I see global identifiers, such as `YES and `NO` (silly), global > identifiers in IE, via NFE. I see cases not considering older browsers > (hasOwnProperty). > > The design of many functions/methods leaks implementation details out > using fake private. This is unnecessary and usually not very hard to avoid. > > I also see some benchmarking interspersed with the code. What does > benchmarking have to do with extending objects? > > http://github.com/sproutit/sproutcore/blob/master/frameworks/runtime/... > > My inline comments as "// (GS) ... ". > > extend: function(props) { > > // (GS) What does benchmarking have to do with extending objects? > // (GS) I suggest removing the benchmarking. You might want to put it in > // (GS) completely separate AOP layer. Or just get rid of it (I would). > var bench = SC.BENCHMARK_OBJECTS ; > if (bench) SC.Benchmark.start('SC.Object.extend') ; > > // build a new constructor and copy class methods. Do this before > // adding any other properties so they are not overwritten by the > // copy. > > // (GS) This looks like you're building up a big global SC.Object with > // (GS) more properties coming from anyone who should call > // (GS) `SC.Object.extend`. What is SC.Object defining? > // > // (GS) Why the underscore here? This is a globally-accessible > // (GS) SC.Object.prototype._object_init; it is not really private. > var prop, ret = function(props) { return this._object_init(props);}; > for(prop in this) { > if (!this.hasOwnProperty(prop)) continue ; > > // (GS) Avoid referencing `this` in static context. > ret[prop] = this[prop]; > } > > // (GS) `hasOwnProperty` won't work in some implementations. > // (GS) Also, `toString` is not the only problematic one; Did you > // (GS) consider `valueOf`? > // manually copy toString() because some JS engines do not enumerate it > > if (this.hasOwnProperty('toString')) ret.toString = this.toString; > > // now setup superclass, guid > ret.superclass = this ; > SC.generateGuid(ret); // setup guid > > ret.subclasses = SC.Set.create(); > this.subclasses.add(ret); // now we can walk a class hierarchy > > // setup new prototype and add properties to it > var base = (ret.prototype = SC.beget(this.prototype)); > var idx, len = arguments.length; > for(idx=0;idx<len;idx++) SC._object_extend(base, arguments[idx]) ; > base.constructor = ret; // save constructor > > // (GS) Again with the benchmarking. > if (bench) SC.Benchmark.end('SC.Object.extend') ; > return ret ; > }, > > I see that function calls various other functions. I see a call to > SC._object_extend. I've modified the code to wrap at 72 chars. > > // (GS) Named FunctionExpression will add a global `_object_extend` > // (GS) property in JScript <= 5.8. I suggest not doing that. > SC._object_extend = function _object_extend(base, ext) { > > // (GS) Suggest throwing an object. That helps some Debuggers get a > // (GS) stack trace (error.stack). > if (!ext) throw "SC.Object.extend expects a non-null value. " > + "Did you forget to 'sc_require' something? Or were you passing a " > + " Protocol to extend() as if it were a mixin?"; > > // (GS) There is not need to leak implementation details to the base > // (GS) object. I suggest avoiding doing that, so that these > // (GS) implementation details remain hidden, and can never be relied > // (GS) on. > // set _kvo_cloned for later use > base._kvo_cloned = null; > > I've given enough suggestions. There is enough complexity to confuse me. > I managed to find SC.Set. > > http://github.com/sproutit/sproutcore/blob/master/frameworks/runtime/... > End. > > How's that? Okay. But isn't this beating a dead horse. Nobody sane would build widgets (or anything else) on top of an old jQuery version. Browsers browser documents, documents contain elements, elements contain attributes. Which of these basic building blocks did Sproutcore get right? (rhetorical, of course).
From: David Mark on 13 Jan 2010 00:23 On Jan 9, 5:40 am, Jorge <jo...(a)jorgechamorro.com> wrote: > On Jan 9, 9:11 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > > (...) > > It's so funny and ridiculous and seems sooo stupid that the same guys > that advocate turning off JS in the browser (many cljs regulars), Who "advocates" turning off JS in the browser (and to whom?) Or do you mean that you want to forget that JS can be turned off so you don't have to consider the most basic degradation path? Too bad, Jorge. Welcome to the "Real World". > feel > themselves as an authority so as to judge somebody else's work whose > main goal/underlying idea don't even understand (e.g., you don't know > a word of cocoa), just by looking at a few lines in their JS source. Cocoa? What does that have to do with any of this? Do you understand the concept of layers at all? They apply to virtually any kind of construction. If the foundation is faulty, what will happen to the building?
From: David Mark on 13 Jan 2010 00:27 On Jan 9, 9:01 am, Jorge <jo...(a)jorgechamorro.com> wrote: > On Jan 9, 2:53 pm, RobG <rg...(a)iinet.net.au> wrote: > > > > > > (e.g., you don't know > > > a word of cocoa), > > > Utterly irrelevant. Apple's Cocoa is a "collection of frameworks, APIs, > > and accompanying runtimes"[1] specifically for Mac OS X developers. That > > is unrelated to a script library that is supposed to be suitable for web > > applications and presumably platforms other than Safari on Mac OS. > > In case you didn't know, SproutCore is Cocoa for the Web. In case you didn't know, you are mad. It doesn't matter what beverage you name it after, the scripts are just browser sniffing compendiums. In other words, it's the sum total of observations made by incompetent developers over a period of years (see also, YUI, Closure, jQuery, etc.) All of the comments are about the state of browsers at the time the scripts were written. They rarely demosntrate any real understanding of the issues. Why do you think they need a million monkeys to "keep up" with three or four browsers?
From: David Mark on 13 Jan 2010 00:56
On Jan 11, 2:13 am, Ross Boucher <rbouc...(a)gmail.com> wrote: > On Jan 10, 11:08 pm, RobG <rg...(a)iinet.net.au> wrote: > > > > > On Jan 11, 4:56 pm, Ross Boucher <rbouc...(a)gmail.com> wrote: > > > > > > I've seen the demos for the 280 north cappucino (same guys). While the > > > > > code is atrocious, they speak and present well. > > > > > I contacted them about their demos (which were similarly dismal) ages > > > > ago. They didn't seem to think it was an issue. There seems to be > > > > something of a disconnect between the public and web personas, perhaps > > > > that is what raises my hackles. > > > > Just pointing out this error. Sproutcore and Cappuccino have nothing > > > to do with each other. > > > OK. > > > > Not sure where this "same guys" idea came from. > > > Also not sure if the rest of these comments are supposed to be about > > > Cappuccino or about Sproutcore. > > > SproutCore. The only comments specifically about Cappuccino are in > > that last paragraph. > > > -- > > Rob > > About the demos? I can't recall any conversation we might have had, > but I'll agree with you. We haven't been keeping them up to date with > the framework, and we haven't made the time to create more. They are > all on Github, and we've started to collect other projects there as > well, which is a step in the right direction. We're planning a new > community site which will also make it easier to find things. Don't bother. |