Guys this is a feature I would love to see in the compiler (and support in linter if required and any other related projects). This would allow code like the following:
goog.require('namespace.*')
...
findHandlerForRequest(request) { for (var clazz in namespace ) { var handler = new clazz(); if (handler.supports(request) { handler.run(request); return; } } throw new Error('Could not find a handler for request');
}
I don't know what this pattern is called (auto discovery??). Anyways, currently closure code always violates the open/closed principle because any client of an interface must always be aware of all implementations by having to explicitly define all goog.requires.
This to me sounds like a major enhancement so I put it here for discussion as its not a huge deal but it would be nice. I'm also a bit intimidated by the compiler code so since I wouldn't be implementing this I don't feel I have the right to add a proper enhancement request.
Any comments? Is this even possible with the current compiler/depsbuilder/linter design?
On Thursday, May 3, 2012 12:09:36 AM UTC-5, Guido Tapia wrote:
> Guys this is a feature I would love to see in the compiler (and support in > linter if required and any other related projects). This would allow code > like the following:
> goog.require('namespace.*')
> ...
> findHandlerForRequest(request) { > for (var clazz in namespace ) { > var handler = new clazz(); > if (handler.supports(request) { > handler.run(request); > return; > } > } > throw new Error('Could not find a handler for request'); > }
> I don't know what this pattern is called (auto discovery??). Anyways, > currently closure code always violates the open/closed principle because > any client of an interface must always be aware of all implementations by > having to explicitly define all goog.requires.
> This to me sounds like a major enhancement so I put it here for discussion > as its not a huge deal but it would be nice. I'm also a bit intimidated by > the compiler code so since I wouldn't be implementing this I don't feel I > have the right to add a proper enhancement request.
> Any comments? Is this even possible with the current > compiler/depsbuilder/linter design?
Off the top of my head, I don't know of anything that would prevent the
wild cards in the requires.
Iterating over members of a namespace is not something that is supported by
ADVANCED compilation, so an alternate registration/discovery mechanism
would be needed, but that doesn't change the core of this proposal.
On Wed, May 2, 2012 at 10:09 PM, Guido Tapia <guido.ta...@gmail.com> wrote:
> Guys this is a feature I would love to see in the compiler (and support in
> linter if required and any other related projects). This would allow code
> like the following:
> goog.require('namespace.*')
> ...
> findHandlerForRequest(request) {
> for (var clazz in namespace ) {
> var handler = new clazz();
> if (handler.supports(request) {
> handler.run(request);
> return;
> }
> }
> throw new Error('Could not find a handler for request');
> }
> I don't know what this pattern is called (auto discovery??). Anyways,
> currently closure code always violates the open/closed principle because
> any client of an interface must always be aware of all implementations by
> having to explicitly define all goog.requires.
> This to me sounds like a major enhancement so I put it here for discussion
> as its not a huge deal but it would be nice. I'm also a bit intimidated by
> the compiler code so since I wouldn't be implementing this I don't feel I
> have the right to add a proper enhancement request.
> Any comments? Is this even possible with the current
> compiler/depsbuilder/linter design?
@Chad: Interfaces are fully supported but discovery of types is not. All clients must be aware of the concrete implementations of their services (by having to goog.require them). @John: I'm not hung up on the discovery approach. The goog.reflect module would also be a good candidate.
On Friday, May 4, 2012 4:21:14 AM UTC+10, John wrote:
> Off the top of my head, I don't know of anything that would prevent the > wild cards in the requires.
> Iterating over members of a namespace is not something that is supported > by ADVANCED compilation, so an alternate registration/discovery mechanism > would be needed, but that doesn't change the core of this proposal.
> On Wed, May 2, 2012 at 10:09 PM, Guido Tapia <guido.ta...@gmail.com>wrote:
>> Guys this is a feature I would love to see in the compiler (and support >> in linter if required and any other related projects). This would allow >> code like the following:
>> goog.require('namespace.*')
>> ...
>> findHandlerForRequest(request) { >> for (var clazz in namespace ) { >> var handler = new clazz(); >> if (handler.supports(request) { >> handler.run(request); >> return; >> } >> } >> throw new Error('Could not find a handler for request'); >> }
>> I don't know what this pattern is called (auto discovery??). Anyways, >> currently closure code always violates the open/closed principle because >> any client of an interface must always be aware of all implementations by >> having to explicitly define all goog.requires.
>> This to me sounds like a major enhancement so I put it here for >> discussion as its not a huge deal but it would be nice. I'm also a bit >> intimidated by the compiler code so since I wouldn't be implementing this I >> don't feel I have the right to add a proper enhancement request.
>> Any comments? Is this even possible with the current >> compiler/depsbuilder/linter design?
The linter does not know about other namespaces -- it cannot know
without scanning the entire fileset. It only looks at one file at a
time. Therefore, it can't dereference wildcards.
On Thu, May 3, 2012 at 2:49 PM, Guido Tapia <guido.ta...@gmail.com> wrote:
> @Chad: Interfaces are fully supported but discovery of types is not. All
> clients must be aware of the concrete implementations of their services (by
> having to goog.require them).
> @John: I'm not hung up on the discovery approach. The goog.reflect module
> would also be a good candidate.
> On Friday, May 4, 2012 4:21:14 AM UTC+10, John wrote:
>> Off the top of my head, I don't know of anything that would prevent the
>> wild cards in the requires.
>> Iterating over members of a namespace is not something that is supported
>> by ADVANCED compilation, so an alternate registration/discovery mechanism
>> would be needed, but that doesn't change the core of this proposal.
>> On Wed, May 2, 2012 at 10:09 PM, Guido Tapia <guido.ta...@gmail.com>
>> wrote:
>>> Guys this is a feature I would love to see in the compiler (and support
>>> in linter if required and any other related projects). This would allow
>>> code like the following:
>>> goog.require('namespace.*')
>>> ...
>>> findHandlerForRequest(request) {
>>> for (var clazz in namespace ) {
>>> var handler = new clazz();
>>> if (handler.supports(request) {
>>> handler.run(request);
>>> return;
>>> }
>>> }
>>> throw new Error('Could not find a handler for request');
>>> }
>>> I don't know what this pattern is called (auto discovery??). Anyways,
>>> currently closure code always violates the open/closed principle because any
>>> client of an interface must always be aware of all implementations by having
>>> to explicitly define all goog.requires.
>>> This to me sounds like a major enhancement so I put it here for
>>> discussion as its not a huge deal but it would be nice. I'm also a bit
>>> intimidated by the compiler code so since I wouldn't be implementing this I
>>> don't feel I have the right to add a proper enhancement request.
>>> Any comments? Is this even possible with the current
>>> compiler/depsbuilder/linter design?
I don't see the linter's precision as a show stopper, it will already
happily let you "require" non-existent things or non-existent inner types.
The linter would simply say "you've required the correct namespace to
fullfill the requirements for this file". This is effectively what it does
now anyway.
On Thu, May 3, 2012 at 3:27 PM, Nathan Naze <nn...@google.com> wrote:
> The linter does not know about other namespaces -- it cannot know
> without scanning the entire fileset. It only looks at one file at a
> time. Therefore, it can't dereference wildcards.
> Nathan
> On Thu, May 3, 2012 at 2:49 PM, Guido Tapia <guido.ta...@gmail.com> wrote:
> > @Chad: Interfaces are fully supported but discovery of types is not. All
> > clients must be aware of the concrete implementations of their services
> (by
> > having to goog.require them).
> > @John: I'm not hung up on the discovery approach. The goog.reflect
> module
> > would also be a good candidate.
> > On Friday, May 4, 2012 4:21:14 AM UTC+10, John wrote:
> >> Off the top of my head, I don't know of anything that would prevent the
> >> wild cards in the requires.
> >> Iterating over members of a namespace is not something that is supported
> >> by ADVANCED compilation, so an alternate registration/discovery
> mechanism
> >> would be needed, but that doesn't change the core of this proposal.
> >> On Wed, May 2, 2012 at 10:09 PM, Guido Tapia <guido.ta...@gmail.com>
> >> wrote:
> >>> Guys this is a feature I would love to see in the compiler (and support
> >>> in linter if required and any other related projects). This would
> allow
> >>> code like the following:
> >>> goog.require('namespace.*')
> >>> ...
> >>> findHandlerForRequest(request) {
> >>> for (var clazz in namespace ) {
> >>> var handler = new clazz();
> >>> if (handler.supports(request) {
> >>> handler.run(request);
> >>> return;
> >>> }
> >>> }
> >>> throw new Error('Could not find a handler for request');
> >>> }
> >>> I don't know what this pattern is called (auto discovery??). Anyways,
> >>> currently closure code always violates the open/closed principle
> because any
> >>> client of an interface must always be aware of all implementations by
> having
> >>> to explicitly define all goog.requires.
> >>> This to me sounds like a major enhancement so I put it here for
> >>> discussion as its not a huge deal but it would be nice. I'm also a bit
> >>> intimidated by the compiler code so since I wouldn't be implementing
> this I
> >>> don't feel I have the right to add a proper enhancement request.
> >>> Any comments? Is this even possible with the current
> >>> compiler/depsbuilder/linter design?
