[Prototype-core] Re: Style Guide for rewrite branch

2008-11-15 Thread T.J. Crowder
> 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

[Prototype-core] Making Joose compatible with Prototype

2008-11-15 Thread Malte
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

[Prototype-core] Re: Style Guide for rewrite branch

2008-11-15 Thread Nick Stakenburg
> 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

[Prototype-core] Re: Style Guide for rewrite branch

2008-11-15 Thread Tobie Langel
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

[Prototype-core] Re: Style Guide for rewrite branch

2008-11-15 Thread Tobie Langel
> > 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. --~--~-~--~--

[Prototype-core] Re: Style Guide for rewrite branch

2008-11-15 Thread kangax
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

[Prototype-core] Re: Making Joose compatible with Prototype

2008-11-15 Thread kangax
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

[Prototype-core] Re: Making Joose compatible with Prototype

2008-11-15 Thread Malte Ubl
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

[Prototype-core] Re: Style Guide for rewrite branch

2008-11-15 Thread Nick Stakenburg
> 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

[Prototype-core] Re: Style Guide for rewrite branch

2008-11-15 Thread kangax
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

[Prototype-core] Re: Style Guide for rewrite branch

2008-11-15 Thread kangax
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

[Prototype-core] Re: Style Guide for rewrite branch

2008-11-15 Thread [EMAIL PROTECTED]
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