On Nov 16, 1:58 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> 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 followi
On Nov 16, 2:58 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
[...]
> Another interresting point is usage of "early or late binding" when
> calling methods from other methods within the same closure
> (i.e.http://gist.github.com/25430)
> Early binding makes Prototype methods sort of frozen,
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
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
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
> 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, 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
> > 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.
--~--~-~--~--
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
> 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
> 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
On Fri, 14 Nov 2008 01:59:07 +0300, kangax <[EMAIL PROTECTED]> wrote:
> My only concern about this pattern is memory usage. There are many
> functions created during branching process, yet only one is returned/
> assigned (and is then used throughout the rest of the application
> life). Those alt
Just a couple of short notes:
> How about not having to run every single one of those tests upfront?
> If tests are defined in let's say Feature.tests they can be run only
> when required instead of upfront. That would prevent running complex
> tests you don't end up using.
Let's not prematurely
If a feature test ends up being used in various sections (dom, event,
string..) deciding on proper placement could become a problem. I think
it's easier to keep feature tests in one place.
Prototype.BrowserFeatures doesn't seem like the right place for those
tests since both features and bugs are
On Nov 13, 2:25 pm, Andrew Dupont <[EMAIL PROTECTED]> wrote:
> Here's what this would look like when genericized into an imaginary
> API:http://gist.github.com/24571
>
> A couple of things:
>
> (1) I'm altogether in favor of this new approach, but it will result
> in less "implicit" organization
Here's what this would look like when genericized into an imaginary
API: http://gist.github.com/24571
A couple of things:
(1) I'm altogether in favor of this new approach, but it will result
in less "implicit" organization of code. A reader of the code will
likely find it harder to scan for the
Hi Tobie,
> I'm actually interested in the pattern, not in the actual code.
Yeah, just wanted to make sure we were looking at the right code
first.
> I investigated a bit more re the typos you mentioned. It happens to be
> an issue with gist which... escaped some of the strings.
Lovely.
So st
I investigated a bit more re the typos you mentioned. It happens to be
an issue with gist which... escaped some of the strings.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this
I'm actually interested in the pattern, not in the actual code.
On Nov 13, 11:49 am, "T.J. Crowder" <[EMAIL PROTECTED]> wrote:
> Tobie,
>
> That code looks a bit off -- like maybe at some point it used to have
> entities that something, somewhere rendered as characters? Even the
> raw version ha
Tobie,
That code looks a bit off -- like maybe at some point it used to have
entities that something, somewhere rendered as characters? Even the
raw version has this for the escapeHTMLWithReplace version:
return this.replace(/&/g,'&').replace(//
g,'>').replace(/"/g, '"');
...which I'm guessing
Thanks for the write-up T.J.
Before we go ahead and document the styles, I'd like to have a bit
more input (with relevant example code, please!) of how we should
handle feature testing.
Here's the originally proposed implementation for String#escapeHTML:
https://gist.github.com/5e0cefdc5e4783f1
21 matches
Mail list logo
