From: Jorge on
On Jan 11, 9:58 am, Jorge <jo...(a)> wrote:
> Mr. Smith does much more than "an error".

From: RobG on
On Jan 11, 6:55 pm, Jorge <jo...(a)> wrote:
> On Jan 11, 1:13 am, RobG <rg...(a)> wrote:
> > There is no need to know about Cocoa at all when reviewing the library
> > code used by SproutCore, criticisms were based purely on its use of
> > javascript. If you can show that a specific criticim is not justified
> > based on some principle of MVC architecture, design pattern, code
> > style or some other relevant point, please do so.
> I'm glad to see that finally, you're beginning to "get it" -albeit
> superficially-, "it" being what the library you're criticizing is
> about.

So you think the fact that the title of the thread is drawn from the
SproutCore web site, that specific examples have been drawn from the
site and published demos and that it requires downloading and
installing the framework to inspect the code means we're just making
it all up?

And that someone could do all that and still have no idea what it's
all about?

> Because ISTM that a basic -at the very least- understanding of
> whatever you're talking about is always a good thing to have before
> criticizing. For example, had you known beforehand that sproutcore was
> about emulating OSX's Cocoa MVC model and basic framework's
> functionality (and no, nothing to do with .NET),

Apparently you haven't understood a single word I've said, and clearly
have no idea that just because SproutCore might be trying to "emulate"
Cocoa, it doesn't make it above criticism of its technical merit.

> you might have
> guessed better -given the caliber of the project- that to achieve that
> it takes -necessarily- more than a few of lines of JS. Then maybe, as
> a second thought, you could have said e.g. that -in your opinion- the
> web is not ready for such things yet (I would not agree), instead of
> blindly ditching something that you don't even know what is. IOW, you
> and the Smith ought to think before you talk.

You have been asked several times to show how the criticisms mentioned
here are invalid, yet you haven't posted a single, logical point in
rebuttal. If you think an MVC architecture necessarily requires large
amounts of client-side processing, or the need for large dumps of data
to the client, you haven't explained why you think so despite having
several opportunities.

This discussion is pointless.

From: Jorge on
On Jan 11, 12:40 pm, RobG <rg...(a)> wrote:
> This discussion is pointless.

Never mind Rob, have a nice day.
From: Garrett Smith on
Andrew Poulos wrote:
> On 11/01/2010 7:01 PM, Jorge wrote:
>> On Jan 11, 8:47 am, Garrett Smith<dhtmlkitc...(a)> wrote:
>>> I can't believe I wrote that. And posted it.
>> That's because you don't think before you talk.
> Lets see. Mr Smith had an error he made pointed out to him and he
> acknowledged it. There have been numerous errors and shortcomings in
> SproutCore pointed out, but for you the "bad" is still Mr Smith?
I did look at the code I reviewed carefully. I did not have time to look
at all of the code. Code review does take time. The code comments I
wrote were fair and should be useful and helpful to the authors. Those
code comments still stand.

The similarities between Sproutcore include influence from Cocoa,
compiling javascript, and variables such as:

var YES = true,
No = false,

Although Sproutcore and Cappucino have some similarities, they are not
written by the same people.

Late night messages tend to have more typos and bungled edits. For some,
late messages can be more emotional. Me, I tend to be more of a hothead
in the AM, which is why I like to put myself in an environment where
that is suitable (lift heavy weight).

The message in respons to Ross' correction was sent out late, and was
immediately followed by a correction.
comp.lang.javascript FAQ:
From: Ross Boucher on
On Jan 11, 8:49 pm, Garrett Smith <dhtmlkitc...(a)> 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. It is there to make
people coming from a Cocoa background more comfortable. 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
arguments against it are stylistic and subjective, but most
importantly it's a completely inconsequential part of both frameworks.