Hi,

> Hmm, I wonder if the original value would still be in the
> arguments array???

Nope. `arguments` is *that* magic. If you have, say:

    function foo(bar)

...then `bar` is an alias for `arguments[0]` and vice-versa. Writing
to `bar` updates `arguments[0]` and writing to `arguments[0]` updates
`bar`. Example: http://jsbin.com/ojomu
--
T.J. Crowder
Independent Software Engineer
mail: tj / crowder software / com
web: www / crowder software / com

On Sep 9, 11:03 pm, "Brian Marquis" <br...@quotepro.com> wrote:
> Blaine,
>
> It's not my code...
>
> I'm trying to debug other people's work, it's rather irritating when I'm
> getting a null pointer exception from code returned via an Ajax call and run
> via executeScripts.
>
> I'm not asking to change the behavior or somehow trap the null value and
> return something else. Just asking for the incoming parameters to be
> preserved. Hmm, I wonder if the original value would still be in the
> arguments array???
>
>
>
> -----Original Message-----
> From: prototype-scriptaculous@googlegroups.com
>
> [mailto:prototype-scriptacul...@googlegroups.com] On Behalf Of Blaine
> Sent: Thursday, September 09, 2010 1:29 PM
> To: Prototype & script.aculo.us
> Subject: [Proto-Scripty] Re: element is null suggestion
>
> I think the way it is is intuitive to JavaScript developers who know
> Document.getElementById().  If the element may return null, then check
> for null dammit ;-) ... just as if you were coding directly with w3c
> API.
>
> WRT console logging, there are tons of places where console logging
> would be useful in Proto, but for whatever reason, it's been decided
> to avoid any dependency on a console device.  I very much doubt that
> this use case is going to overturn that policy.
>
> On Sep 8, 12:01 pm, Brian Marquis <br...@quotepro.com> wrote:
> > In numerous places throughout the Prototype library, the element
> > parameter is extended and overwritten. This code typically resembles
> > the following code:
>
> > someMethod: function(element) {
> >   element = $(element);
> >   return element.someOtherMethod();
>
> > }
>
> > For me, at least, this makes debugging more difficult than it could
> > be. Consider the following modification
>
> > someMethod: function(desiredElement) {
> >   element = $(desiredElement);
> >   return element.someOtherMethod();
>
> > }
>
> > Now I can place a Breakpoint on Error in Firebug and instantly know
> > which element is causing the problem. Or perhaps even better would be
> > a modification to perform console logging if $(element) would return
> > null.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prototype & script.aculo.us" group.
> To post to this group, send email to
> prototype-scriptacul...@googlegroups.com.
> To unsubscribe from this group, send email to
> prototype-scriptaculous+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/prototype-scriptaculous?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to