> Returning functions this way doesn't imply they do not have names. I've
> successfully used pattern "return someNamed function(){ ... }" for
> debugging.
You mean "return function someNamed() { ... }", right? That's fine by
the specs, because the FunctionExpression is allowed to have an
option
Hey,
we are working on making the JS meta system Joose (http://
code.google.com/p/joose-js/) compatible with Prototype.js
We had to make some pretty serious changes to cope with Prototype's
prototype extension and especially some global identifiers like
"Class" and "Prototype" that are used in b
> You mean "return function someNamed() { ... }", right? That's fine by the
> specs
Love it.
> Let's not prematurely optimize.
My proposal isn't just an optimization but a different approach for
the more complex tests used throughout the library. You asked for
feedback on how to handle featur
sorry, Kangax for the delay in getting back to you. My computer turned
off before I could click send last night.
Of course, we can return named function.
What I'd want to avoid, however, (for measurable[1] performance hit
_every time the function is called_) is multiple closures.
So we should b
> > I actually don't think these should be made public.
>
> What's the harm there? Like with Prototype.BrowserFeatures it would
> only make things easier internally.
Whenever you make something public, you have to continue supporting
it. This makes refactoring more complex.
--~--~-~--~--
On Nov 15, 4:56 am, "T.J. Crowder" <[EMAIL PROTECTED]> wrote:
> > Returning functions this way doesn't imply they do not have names. I've
> > successfully used pattern "return someNamed function(){ ... }" for
> > debugging.
>
> You mean "return function someNamed() { ... }", right? That's fine by
On Nov 15, 7:36 am, Malte <[EMAIL PROTECTED]> wrote:
> Hey,
>
> we are working on making the JS meta system Joose (http://
> code.google.com/p/joose-js/) compatible with Prototype.js
>
> We had to make some pretty serious changes to cope with Prototype's
> prototype extension and especially some g
Hey,
On Sat, Nov 15, 2008 at 8:18 PM, kangax <[EMAIL PROTECTED]> wrote:
>
> On Nov 15, 7:36 am, Malte <[EMAIL PROTECTED]> wrote:
>> Joose provides a Role called Joose.Storage that makes Joose objects
>> storable. The preferred method is JSON and a custom toJSON method is
>> provided to make seri
> Whenever you make something public, you have to continue supporting
> it. This makes refactoring more complex.
Yeah, but if those tests are in one place there's not much complexity
to it.
If Prototype itself was wrapped in a closure beautifying the internals
would become so much easier, these
On Nov 15, 9:58 am, Tobie Langel <[EMAIL PROTECTED]> wrote:
> sorry, Kangax for the delay in getting back to you. My computer turned
> off before I could click send last night.
>
> Of course, we can return named function.
>
> What I'd want to avoid, however, (for measurable[1] performance hit
> _e
On Nov 15, 10:00 am, Tobie Langel <[EMAIL PROTECTED]> wrote:
> > > I actually don't think these should be made public.
>
> > What's the harm there? Like with Prototype.BrowserFeatures it would
> > only make things easier internally.
>
> Whenever you make something public, you have to continue supp
Here is my take,
I'm also altogether with this incoming pattern.
PDoc blocks could indeed demarcate those sections, and be used to
provide (browser|feature)-specific technical documentation.
My proposal is the following (http://gist.github.com/25421), where by
method appear :
- classical implem
12 matches
Mail list logo
