goog.scope and require aliases redundancy

[GoogleCodeExporter]

So imagine your source file depends on 10 or more classes/functions from the 
library. You're terribly annoyed by having to type the whole namespace before 
every call (naturally, I don't want to retype the same shit all over) so you 
discover goog.scope hooray! What happens? Well, you have to retype the 
dependency twice, once in goog.require call, and another time while aliasing 
inside goog.scope. Quite stupid IMHO who designed this crap? Can't you guys 
inspire yourself a bit with require.js (which I never used) and return 
something meaningful from goog.require? I know you need to optimize and stuff, 
but for what price? Annoying the hell out of you user base? C'mon. What's the 
deal? Can't we find a neat solution for this?

Original issue reported on code.google.com by dusan.ma...@gmail.com on 26 May 2012 at 10:02

[GoogleCodeExporter]

First of all, we appreciate the comments, but do not appreciate the tone. If 
you're going to spend the time submitting a bug, it seems rather bizarre to be 
rude about it.

You've made a couple assumptions that are worth fixing:

There's not necessarily a 1:1 correspondence between the aliases and the 
requires. Many people just require classes but alias their namespaces.

In requireJS, the dependency tree is built at run-time, but in Closure it is 
built at compile-time. So there are some important differences in what designs 
are possible, particularly around synchronous vs. asynchronous APIs, and how 
hard it is to build tools. Good tools for managing this are important to us.

If you read the goog.scope design doc, 
https://docs.google.com/document/pub?id=1ETFAuh2kaXMVL-vafUYhaWlhl6b5D9TOvboVg7Z
l68Y
it talks about a lot of the issues you raised. goog.scope was proposed as a 
stepping stone to less verbose syntaxes, but so far, no one has really been 
excited about the other syntaxes (the doc talks about some possibilities)

Original comment by Nicholas.J.Santos on 26 May 2012 at 10:33

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Yes I'm familiar with that doc. (the scopify script is a joke? is anyone really 
using it?) Today the consensus seems to be AMD, until ES6 is out and widely 
available. The spec surely isn't a silver bullet, and there's still lot to 
desire.

You decided to abandon the require-return option because of async. loading, 
that's however quite questionable. In production mode you only need async. 
loading for _on demand modules_, and IMHO, the best solution to this would be 
to make simple mechanism ala GWT split points. That would leave us with no 
reason not to use synchronous loading (during testing), in prod. all is 
compiled and hence no need for async.

@nicolas: it seems rather bizarre to waste 2 (now 3) sentences for one's lingo.

Original comment by dusan.ma...@gmail.com on 27 May 2012 at 12:06

[GoogleCodeExporter]

goog.scope() is still being investigated, but, without massive changes to our 
toolchains, we're stuck without support for aliasing in goog.require() calls.  
Not pursuing this change.

Original comment by nn...@google.com on 30 May 2012 at 11:57

• Changed state: WontFix