I need to get the argument names of a function object. I can do it by
calling aFunc.toString() to get the source, and then parse the source to get
the argument names, but before I go down that path, is there an easier way
to do this?
To illustrate:
function funcThatGetsArgumentNames(func) {
// this returns an array of the argument names of the passed function
object; if I can't find a better way, I'll call .toString() (after
validating it's a function object) and parse the source
}
var f = function(foo, bar, baz) {}
function funcThatNeedsArgumentName() {
argNames = funcThatGetsArgumentNames(f)
// argNames should now be [ "foo", "bar", "baz" ]
}
Thanks for the help,
Drew
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
On Sat, May 22, 2010 at 3:46 PM, Drew Miller <e...@anglicangeek.com> wrote:
> I need to get the argument names of a function object. I can do it by
> calling aFunc.toString() to get the source, and then parse the source to get
> the argument names, but before I go down that path, is there an easier way
> to do this?
No. Also, bear in mind that JavaScript engines vary on how toSource a
function so doing this generally is even harder, and sometimes
impossible.
Kris Kowal
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
On May 22, 2010 9:29 PM, "Kris Kowal" <kris.ko...@cixar.com> wrote:
On Sat, May 22, 2010 at 3:46 PM, Drew Miller <e...@anglicangeek.com> wrote:
> I need to get the argum...
No. Also, bear in mind that JavaScript engines vary on how toSource a
function so doing this generally is even harder, and sometimes
impossible.
Kris Kowal
-- You received this message because you are subscribed to the Google Groups
"nodejs" group.
To po...
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Nick, this is for binding objects from various sources to HTTP request
handlers based on what is "requested" by the handler via its arguments. I
know there are various other ways to do this, many of them perfectly
acceptable (I most often see other folks push stuff onto this with call);
they're just not what I want. What I want is to support things like this:
webFx.handle("/a/static/path", function(request) { //... }
webFx.handle("a/route/with/:param, function(param) { // I don't need a
request object }
webFx.handle("a/route/with/:param, function(param, request, user) { // I
need the authenticated user }
webFx.handle("a/route/with/:param, function(session, param, user) { // I
want session state, and order shouldn't matter }
webFx.handle("a/route/with/:param, function(session, param, user,
someObjectIRegisteredViaDependyInjection) { // objects can come from many
sources }
Again, I know of many ways to provide the means for what I want to do here,
but this is the way I want my API. I already have a JavaScript parser
written in JavaScript from another project, so parsing the source of the
handler function is just fine. I was just curious if Node offered something
special in this regard (I wasn't expecting it did).
Kris, this will only target Node; I'm not worried about differing toString()
behavior on function objects in other engines.
Thanks,
Drew
On Sat, May 22, 2010 at 6:32 PM, Nicholas Campbell <
nicholas.j.campb...@gmail.com> wrote:
> What are you attempting to do with this?
> - Nick
> On May 22, 2010 9:29 PM, "Kris Kowal" <kris.ko...@cixar.com> wrote:
> On Sat, May 22, 2010 at 3:46 PM, Drew Miller <e...@anglicangeek.com> wrote:
> > I need to get the argum...
> No. Also, bear in mind that JavaScript engines vary on how toSource a
> function so doing this generally is even harder, and sometimes
> impossible.
> Kris Kowal
> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To po...
> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
On Sat, May 22, 2010 at 7:03 PM, Drew Miller <e...@anglicangeek.com> wrote:
> webFx.handle("/a/static/path", function(request) { //... }
> webFx.handle("a/route/with/:param, function(param) { // I don't need a
> request object }
> webFx.handle("a/route/with/:param, function(param, request, user) { // I
> need the authenticated user }
> webFx.handle("a/route/with/:param, function(session, param, user) { // I
> want session state, and order shouldn't matter }
> webFx.handle("a/route/with/:param, function(session, param, user,
> someObjectIRegisteredViaDependyInjection) { // objects can come from many
> sources }
If you're looking to have position independence and optionality, I
highly recommend having your handlers just accept an object with the
mapped keywords, although I'm sure you can make it work the way you
want given your constraints.
Kris Kowal
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Thanks Kris; I considered that approach, and while it's obviously quite
easy, it's not as pretty. More importantly, it doesn't communicate what the
handler actually needs.
Making it optional is only part of the problem; I don't want to spend time
building objects per request unless the handler needs them. Again, I know I
could handle that part of the problem in another way as well, but I can't
think of a way that meets the (okay, my) pretty criterion.
If we're going to spend lots of time in a framework, why not freshen it up?
Starting at ugly code all day is bad for the soul.
On Sat, May 22, 2010 at 7:07 PM, Kris Kowal <kris.ko...@cixar.com> wrote:
> On Sat, May 22, 2010 at 7:03 PM, Drew Miller <e...@anglicangeek.com> wrote:
> > webFx.handle("/a/static/path", function(request) { //... }
> > webFx.handle("a/route/with/:param, function(param) { // I don't need a
> > request object }
> > webFx.handle("a/route/with/:param, function(param, request, user) { // I
> > need the authenticated user }
> > webFx.handle("a/route/with/:param, function(session, param, user) { // I
> > want session state, and order shouldn't matter }
> > webFx.handle("a/route/with/:param, function(session, param, user,
> > someObjectIRegisteredViaDependyInjection) { // objects can come from many
> > sources }
> If you're looking to have position independence and optionality, I
> highly recommend having your handlers just accept an object with the
> mapped keywords, although I'm sure you can make it work the way you
> want given your constraints.
> Kris Kowal
> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
> I need to get the argument names of a function object. I can do it by calling aFunc.toString() to get the source, and then parse the source to get the argument names, but before I go down that path, is there an easier way to do this?
> To illustrate:
> function funcThatGetsArgumentNames(func) {
> // this returns an array of the argument names of the passed function object; if I can't find a better way, I'll call .toString() (after validating it's a function object) and parse the source
> }
> var f = function(foo, bar, baz) {}
> function funcThatNeedsArgumentName() {
> argNames = funcThatGetsArgumentNames(f)
> // argNames should now be [ "foo", "bar", "baz" ]
> }
> Thanks for the help,
> Drew
> -- > You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>> I need to get the argument names of a function object. I can do it by calling aFunc.toString() to get the source, and then parse the source to get the argument names, but before I go down that path, is there an easier way to do this?
>> To illustrate:
>> function funcThatGetsArgumentNames(func) {
>> // this returns an array of the argument names of the passed function object; if I can't find a better way, I'll call .toString() (after validating it's a function object) and parse the source
>> }
>> var f = function(foo, bar, baz) {}
>> function funcThatNeedsArgumentName() {
>> argNames = funcThatGetsArgumentNames(f)
>> // argNames should now be [ "foo", "bar", "baz" ]
>> }
>> Thanks for the help,
>> Drew
>> -- >> You received this message because you are subscribed to the Google Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com.
>> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
> I need to get the argument names of a function object. I can do it by
> calling aFunc.toString() to get the source, and then parse the source to get
> the argument names, but before I go down that path, is there an easier way
> to do this?
> To illustrate:
> function funcThatGetsArgumentNames(func) {
> // this returns an array of the argument names of the passed function
> object; if I can't find a better way, I'll call .toString() (after
> validating it's a function object) and parse the source
> }
> var f = function(foo, bar, baz) {}
> function funcThatNeedsArgumentName() {
> argNames = funcThatGetsArgumentNames(f)
> // argNames should now be [ "foo", "bar", "baz" ]
> }
> Thanks for the help,
> Drew
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Wouldn't this require you to always use the same argument names for
the handle functions? This might become a problem if you want a
handler that creates a new handler but still need access to the outer
handlers arguments, however this might be a very special case.
On May 23, 4:03 am, Drew Miller <e...@anglicangeek.com> wrote:
> Nick, this is for binding objects from various sources to HTTP request
> handlers based on what is "requested" by the handler via its arguments. I
> know there are various other ways to do this, many of them perfectly
> acceptable (I most often see other folks push stuff onto this with call);
> they're just not what I want. What I want is to support things like this:
> webFx.handle("/a/static/path", function(request) { //... }
> webFx.handle("a/route/with/:param, function(param) { // I don't need a
> request object }
> webFx.handle("a/route/with/:param, function(param, request, user) { // I
> need the authenticated user }
> webFx.handle("a/route/with/:param, function(session, param, user) { // I
> want session state, and order shouldn't matter }
> webFx.handle("a/route/with/:param, function(session, param, user,
> someObjectIRegisteredViaDependyInjection) { // objects can come from many
> sources }
> Again, I know of many ways to provide the means for what I want to do here,
> but this is the way I want my API. I already have a JavaScript parser
> written in JavaScript from another project, so parsing the source of the
> handler function is just fine. I was just curious if Node offered something
> special in this regard (I wasn't expecting it did).
> Kris, this will only target Node; I'm not worried about differing toString()
> behavior on function objects in other engines.
> Thanks,
> Drew
> On Sat, May 22, 2010 at 6:32 PM, Nicholas Campbell <
> nicholas.j.campb...@gmail.com> wrote:
> > What are you attempting to do with this?
> > - Nick
> > On May 22, 2010 9:29 PM, "Kris Kowal" <kris.ko...@cixar.com> wrote:
> > On Sat, May 22, 2010 at 3:46 PM, Drew Miller <e...@anglicangeek.com> wrote:
> > > I need to get the argum...
> > No. Also, bear in mind that JavaScript engines vary on how toSource a
> > function so doing this generally is even harder, and sometimes
> > impossible.
> > Kris Kowal
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To po...
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nodejs@googlegroups.com.
> > To unsubscribe from this group, send email to
> > nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
JavaScript doesn't give you access to the param names precisely
because this is a terrible idea. The names of the arguments are the
exclusive domain of the function itself, and not intended to be
shared. What if there's already some variable called "param" that
I've closed over, and need access to? What if I'd rather call it "p"
or "parameter" than "param" because it makes the code more clear?
You can use function.length to get the number of declared arguments
(which may not be the number of arguments that it's aware of!), or
function.name to get the name of the function (or "" if you didn't
give it one).
But keying off the argument names is just brittle cleverness of the
worst sort. Please don't do this terrible thing you're contemplating.
I *promise* you there's a better way than this madness.
Position independence and optionality means that you should use a
single object as the argument. Or, just send everything. Passing an
object handle to a function is ludicrously cheap, it's not like it has
to create a whole new object. If you *really* need to specify what's
going to e passed to the handler, you could do something like this:
// specify what gets tacked onto the single hash object
// myHandlerFn({ request : requestObject, session: sessionInfo })
webFx.handle("route", myHandlerFn, { request : true, session:true })
// or, specify which args you want, and in which order
// myHandlerFn(sessionInfo, requestObject)
webFx.handle("route", myHandlerFn, "session", "request")
// compare to this one, which gets called like:
// myOtherHandler(requestObject, sessionInfo, paramList)
webFx.handle("route", myOtherHandler, "request", "session", "param")
On Sun, May 23, 2010 at 00:52, Adam <popz...@gmail.com> wrote:
> Wouldn't this require you to always use the same argument names for
> the handle functions? This might become a problem if you want a
> handler that creates a new handler but still need access to the outer
> handlers arguments, however this might be a very special case.
> On May 23, 4:03 am, Drew Miller <e...@anglicangeek.com> wrote:
>> Nick, this is for binding objects from various sources to HTTP request
>> handlers based on what is "requested" by the handler via its arguments. I
>> know there are various other ways to do this, many of them perfectly
>> acceptable (I most often see other folks push stuff onto this with call);
>> they're just not what I want. What I want is to support things like this:
>> webFx.handle("/a/static/path", function(request) { //... }
>> webFx.handle("a/route/with/:param, function(param) { // I don't need a
>> request object }
>> webFx.handle("a/route/with/:param, function(param, request, user) { // I
>> need the authenticated user }
>> webFx.handle("a/route/with/:param, function(session, param, user) { // I
>> want session state, and order shouldn't matter }
>> webFx.handle("a/route/with/:param, function(session, param, user,
>> someObjectIRegisteredViaDependyInjection) { // objects can come from many
>> sources }
>> Again, I know of many ways to provide the means for what I want to do here,
>> but this is the way I want my API. I already have a JavaScript parser
>> written in JavaScript from another project, so parsing the source of the
>> handler function is just fine. I was just curious if Node offered something
>> special in this regard (I wasn't expecting it did).
>> Kris, this will only target Node; I'm not worried about differing toString()
>> behavior on function objects in other engines.
>> Thanks,
>> Drew
>> On Sat, May 22, 2010 at 6:32 PM, Nicholas Campbell <
>> nicholas.j.campb...@gmail.com> wrote:
>> > What are you attempting to do with this?
>> > - Nick
>> > On May 22, 2010 9:29 PM, "Kris Kowal" <kris.ko...@cixar.com> wrote:
>> > On Sat, May 22, 2010 at 3:46 PM, Drew Miller <e...@anglicangeek.com> wrote:
>> > > I need to get the argum...
>> > No. Also, bear in mind that JavaScript engines vary on how toSource a
>> > function so doing this generally is even harder, and sometimes
>> > impossible.
>> > Kris Kowal
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "nodejs" group.
>> > To po...
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "nodejs" group.
>> > To post to this group, send email to nodejs@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
>> > .
>> > For more options, visit this group at
>> >http://groups.google.com/group/nodejs?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com.
>> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
>> For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Thanks for the feedback Isaac. I considered all of these points before
settling on this approach.
And I would never build a framework that didn't accomodate all of
them. But it'll work for the common scenarios (mine, at least), and
there will be ways to accomodate the uncommon ones. So, 90% of my code
will easy to read and intention-revealing.
And, who does it hurt? This fx is for me, and I don't expect anyone
else to use it. If I'm wrong, there will be pain and friction in my
code and I'll change.
I've never understood why people have strong reactions to trivial or
inconsequential matters. :)
Cheers,
Drew
Sent from my iPhone
On May 23, 2010, at 9:59 AM, Isaac Schlueter <i...@izs.me> wrote:
> JavaScript doesn't give you access to the param names precisely
> because this is a terrible idea. The names of the arguments are the
> exclusive domain of the function itself, and not intended to be
> shared. What if there's already some variable called "param" that
> I've closed over, and need access to? What if I'd rather call it "p"
> or "parameter" than "param" because it makes the code more clear?
> You can use function.length to get the number of declared arguments
> (which may not be the number of arguments that it's aware of!), or
> function.name to get the name of the function (or "" if you didn't
> give it one).
> But keying off the argument names is just brittle cleverness of the
> worst sort. Please don't do this terrible thing you're contemplating.
> I *promise* you there's a better way than this madness.
> Position independence and optionality means that you should use a
> single object as the argument. Or, just send everything. Passing an
> object handle to a function is ludicrously cheap, it's not like it has
> to create a whole new object. If you *really* need to specify what's
> going to e passed to the handler, you could do something like this:
> // specify what gets tacked onto the single hash object
> // myHandlerFn({ request : requestObject, session: sessionInfo })
> webFx.handle("route", myHandlerFn, { request : true, session:true })
> // or, specify which args you want, and in which order
> // myHandlerFn(sessionInfo, requestObject)
> webFx.handle("route", myHandlerFn, "session", "request")
> // compare to this one, which gets called like:
> // myOtherHandler(requestObject, sessionInfo, paramList)
> webFx.handle("route", myOtherHandler, "request", "session", "param")
> --i
> On Sun, May 23, 2010 at 00:52, Adam <popz...@gmail.com> wrote:
>> Wouldn't this require you to always use the same argument names for
>> the handle functions? This might become a problem if you want a
>> handler that creates a new handler but still need access to the outer
>> handlers arguments, however this might be a very special case.
>> On May 23, 4:03 am, Drew Miller <e...@anglicangeek.com> wrote:
>>> Nick, this is for binding objects from various sources to HTTP
>>> request
>>> handlers based on what is "requested" by the handler via its
>>> arguments. I
>>> know there are various other ways to do this, many of them perfectly
>>> acceptable (I most often see other folks push stuff onto this with
>>> call);
>>> they're just not what I want. What I want is to support things
>>> like this:
>>> webFx.handle("/a/static/path", function(request) { //... }
>>> webFx.handle("a/route/with/:param, function(param) { // I don't
>>> need a
>>> request object }
>>> webFx.handle("a/route/with/:param, function(param, request, user)
>>> { // I
>>> need the authenticated user }
>>> webFx.handle("a/route/with/:param, function(session, param, user)
>>> { // I
>>> want session state, and order shouldn't matter }
>>> webFx.handle("a/route/with/:param, function(session, param, user,
>>> someObjectIRegisteredViaDependyInjection) { // objects can come
>>> from many
>>> sources }
>>> Again, I know of many ways to provide the means for what I want to
>>> do here,
>>> but this is the way I want my API. I already have a JavaScript
>>> parser
>>> written in JavaScript from another project, so parsing the source
>>> of the
>>> handler function is just fine. I was just curious if Node offered
>>> something
>>> special in this regard (I wasn't expecting it did).
>>> Kris, this will only target Node; I'm not worried about differing
>>> toString()
>>> behavior on function objects in other engines.
>>> Thanks,
>>> Drew
>>> On Sat, May 22, 2010 at 6:32 PM, Nicholas Campbell <
>>> nicholas.j.campb...@gmail.com> wrote:
>>>> What are you attempting to do with this?
>>>> - Nick
>>>> On May 22, 2010 9:29 PM, "Kris Kowal" <kris.ko...@cixar.com> wrote:
>>>> On Sat, May 22, 2010 at 3:46 PM, Drew Miller
>>>> <e...@anglicangeek.com> wrote:
>>>>> I need to get the argum...
>>>> No. Also, bear in mind that JavaScript engines vary on how
>>>> toSource a
>>>> function so doing this generally is even harder, and sometimes
>>>> impossible.
>>>> Kris Kowal
>>>> --
>>>> You received this message because you are subscribed to the
>>>> Google Groups
>>>> "nodejs" group.
>>>> To po...
>>>> --
>>>> You received this message because you are subscribed to the
>>>> Google Groups
>>>> "nodejs" group.
>>>> To post to this group, send email to nodejs@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> nodejs+unsubscribe@googlegroups.com<nodejs >>>> %2Bunsubscribe@googlegroups.com>
>>>> .
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/nodejs?hl=en.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to nodejs@googlegroups.com.
>>> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com >>> .
>>> For more options, visit this group athttp://groups.google.com/ >>> group/nodejs?hl=en.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com.
>> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com >> .
>> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en >> .
> -- > You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en > .
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
> JavaScript doesn't give you access to the param names precisely
> because this is a terrible idea. The names of the arguments are the
> exclusive domain of the function itself, and not intended to be
> shared. What if there's already some variable called "param" that
> I've closed over, and need access to? What if I'd rather call it "p"
> or "parameter" than "param" because it makes the code more clear?
> You can use function.length to get the number of declared arguments
> (which may not be the number of arguments that it's aware of!), or
> function.name to get the name of the function (or "" if you didn't
> give it one).
> But keying off the argument names is just brittle cleverness of the
> worst sort. Please don't do this terrible thing you're contemplating.
> I *promise* you there's a better way than this madness.
> Position independence and optionality means that you should use a
> single object as the argument. Or, just send everything. Passing an
> object handle to a function is ludicrously cheap, it's not like it has
> to create a whole new object. If you *really* need to specify what's
> going to e passed to the handler, you could do something like this:
> // specify what gets tacked onto the single hash object
> // myHandlerFn({ request : requestObject, session: sessionInfo })
> webFx.handle("route", myHandlerFn, { request : true, session:true })
> // or, specify which args you want, and in which order
> // myHandlerFn(sessionInfo, requestObject)
> webFx.handle("route", myHandlerFn, "session", "request")
> // compare to this one, which gets called like:
> // myOtherHandler(requestObject, sessionInfo, paramList)
> webFx.handle("route", myOtherHandler, "request", "session", "param")
> --i
> On Sun, May 23, 2010 at 00:52, Adam <popz...@gmail.com> wrote:
>> Wouldn't this require you to always use the same argument names for
>> the handle functions? This might become a problem if you want a
>> handler that creates a new handler but still need access to the outer
>> handlers arguments, however this might be a very special case.
>> On May 23, 4:03 am, Drew Miller <e...@anglicangeek.com> wrote:
>>> Nick, this is for binding objects from various sources to HTTP
>>> request
>>> handlers based on what is "requested" by the handler via its
>>> arguments. I
>>> know there are various other ways to do this, many of them perfectly
>>> acceptable (I most often see other folks push stuff onto this with
>>> call);
>>> they're just not what I want. What I want is to support things
>>> like this:
>>> webFx.handle("/a/static/path", function(request) { //... }
>>> webFx.handle("a/route/with/:param, function(param) { // I don't
>>> need a
>>> request object }
>>> webFx.handle("a/route/with/:param, function(param, request, user)
>>> { // I
>>> need the authenticated user }
>>> webFx.handle("a/route/with/:param, function(session, param, user)
>>> { // I
>>> want session state, and order shouldn't matter }
>>> webFx.handle("a/route/with/:param, function(session, param, user,
>>> someObjectIRegisteredViaDependyInjection) { // objects can come
>>> from many
>>> sources }
>>> Again, I know of many ways to provide the means for what I want to
>>> do here,
>>> but this is the way I want my API. I already have a JavaScript
>>> parser
>>> written in JavaScript from another project, so parsing the source
>>> of the
>>> handler function is just fine. I was just curious if Node offered
>>> something
>>> special in this regard (I wasn't expecting it did).
>>> Kris, this will only target Node; I'm not worried about differing
>>> toString()
>>> behavior on function objects in other engines.
>>> Thanks,
>>> Drew
>>> On Sat, May 22, 2010 at 6:32 PM, Nicholas Campbell <
>>> nicholas.j.campb...@gmail.com> wrote:
>>>> What are you attempting to do with this?
>>>> - Nick
>>>> On May 22, 2010 9:29 PM, "Kris Kowal" <kris.ko...@cixar.com> wrote:
>>>> On Sat, May 22, 2010 at 3:46 PM, Drew Miller
>>>> <e...@anglicangeek.com> wrote:
>>>>> I need to get the argum...
>>>> No. Also, bear in mind that JavaScript engines vary on how
>>>> toSource a
>>>> function so doing this generally is even harder, and sometimes
>>>> impossible.
>>>> Kris Kowal
>>>> --
>>>> You received this message because you are subscribed to the
>>>> Google Groups
>>>> "nodejs" group.
>>>> To po...
>>>> --
>>>> You received this message because you are subscribed to the
>>>> Google Groups
>>>> "nodejs" group.
>>>> To post to this group, send email to nodejs@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> nodejs+unsubscribe@googlegroups.com<nodejs >>>> %2Bunsubscribe@googlegroups.com>
>>>> .
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/nodejs?hl=en.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to nodejs@googlegroups.com.
>>> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com >>> .
>>> For more options, visit this group athttp://groups.google.com/ >>> group/nodejs?hl=en.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com.
>> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com >> .
>> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en >> .
> -- > You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en > .
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
> Thanks for the feedback Isaac. I considered all of these points
> before settling on this approach.
> And I would never build a framework that didn't accomodate all of
> them. But it'll work for the common scenarios (mine, at least), and
> there will be ways to accomodate the uncommon ones. So, 90% of my
> code will easy to read and intention-revealing.
> And, who does it hurt? This fx is for me, and I don't expect anyone
> else to use it. If I'm wrong, there will be pain and friction in my
> code and I'll change.
> I've never understood why people have strong reactions to trivial or
> inconsequential matters. :)
> Cheers,
> Drew
> Sent from my iPhone
> On May 23, 2010, at 9:59 AM, Isaac Schlueter <i...@izs.me> wrote:
>> Oh, no, Doing It Wrong! Make it stop!
>> JavaScript doesn't give you access to the param names precisely
>> because this is a terrible idea. The names of the arguments are the
>> exclusive domain of the function itself, and not intended to be
>> shared. What if there's already some variable called "param" that
>> I've closed over, and need access to? What if I'd rather call it "p"
>> or "parameter" than "param" because it makes the code more clear?
>> You can use function.length to get the number of declared arguments
>> (which may not be the number of arguments that it's aware of!), or
>> function.name to get the name of the function (or "" if you didn't
>> give it one).
>> But keying off the argument names is just brittle cleverness of the
>> worst sort. Please don't do this terrible thing you're
>> contemplating.
>> I *promise* you there's a better way than this madness.
>> Position independence and optionality means that you should use a
>> single object as the argument. Or, just send everything. Passing an
>> object handle to a function is ludicrously cheap, it's not like it
>> has
>> to create a whole new object. If you *really* need to specify what's
>> going to e passed to the handler, you could do something like this:
>> // specify what gets tacked onto the single hash object
>> // myHandlerFn({ request : requestObject, session: sessionInfo })
>> webFx.handle("route", myHandlerFn, { request : true, session:true })
>> // or, specify which args you want, and in which order
>> // myHandlerFn(sessionInfo, requestObject)
>> webFx.handle("route", myHandlerFn, "session", "request")
>> // compare to this one, which gets called like:
>> // myOtherHandler(requestObject, sessionInfo, paramList)
>> webFx.handle("route", myOtherHandler, "request", "session", "param")
>> --i
>> On Sun, May 23, 2010 at 00:52, Adam <popz...@gmail.com> wrote:
>>> Wouldn't this require you to always use the same argument names for
>>> the handle functions? This might become a problem if you want a
>>> handler that creates a new handler but still need access to the
>>> outer
>>> handlers arguments, however this might be a very special case.
>>> On May 23, 4:03 am, Drew Miller <e...@anglicangeek.com> wrote:
>>>> Nick, this is for binding objects from various sources to HTTP
>>>> request
>>>> handlers based on what is "requested" by the handler via its
>>>> arguments. I
>>>> know there are various other ways to do this, many of them
>>>> perfectly
>>>> acceptable (I most often see other folks push stuff onto this
>>>> with call);
>>>> they're just not what I want. What I want is to support things
>>>> like this:
>>>> webFx.handle("/a/static/path", function(request) { //... }
>>>> webFx.handle("a/route/with/:param, function(param) { // I don't
>>>> need a
>>>> request object }
>>>> webFx.handle("a/route/with/:param, function(param, request, user)
>>>> { // I
>>>> need the authenticated user }
>>>> webFx.handle("a/route/with/:param, function(session, param, user)
>>>> { // I
>>>> want session state, and order shouldn't matter }
>>>> webFx.handle("a/route/with/:param, function(session, param, user,
>>>> someObjectIRegisteredViaDependyInjection) { // objects can come
>>>> from many
>>>> sources }
>>>> Again, I know of many ways to provide the means for what I want
>>>> to do here,
>>>> but this is the way I want my API. I already have a JavaScript
>>>> parser
>>>> written in JavaScript from another project, so parsing the source
>>>> of the
>>>> handler function is just fine. I was just curious if Node offered
>>>> something
>>>> special in this regard (I wasn't expecting it did).
>>>> Kris, this will only target Node; I'm not worried about differing
>>>> toString()
>>>> behavior on function objects in other engines.
>>>> Thanks,
>>>> Drew
>>>> On Sat, May 22, 2010 at 6:32 PM, Nicholas Campbell <
>>>> nicholas.j.campb...@gmail.com> wrote:
>>>>> What are you attempting to do with this?
>>>>> - Nick
>>>>> On May 22, 2010 9:29 PM, "Kris Kowal" <kris.ko...@cixar.com>
>>>>> wrote:
>>>>> On Sat, May 22, 2010 at 3:46 PM, Drew Miller
>>>>> <e...@anglicangeek.com> wrote:
>>>>>> I need to get the argum...
>>>>> No. Also, bear in mind that JavaScript engines vary on how
>>>>> toSource a
>>>>> function so doing this generally is even harder, and sometimes
>>>>> impossible.
>>>>> Kris Kowal
>>>>> --
>>>>> You received this message because you are subscribed to the
>>>>> Google Groups
>>>>> "nodejs" group.
>>>>> To po...
>>>>> --
>>>>> You received this message because you are subscribed to the
>>>>> Google Groups
>>>>> "nodejs" group.
>>>>> To post to this group, send email to nodejs@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> nodejs+unsubscribe@googlegroups.com<nodejs >>>>> %2Bunsubscribe@googlegroups.com>
>>>>> .
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/nodejs?hl=en.
>>>> --
>>>> You received this message because you are subscribed to the
>>>> Google Groups "nodejs" group.
>>>> To post to this group, send email to nodejs@googlegroups.com.
>>>> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com >>>> .
>>>> For more options, visit this group athttp://groups.google.com/ >>>> group/nodejs?hl=en.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to nodejs@googlegroups.com.
>>> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com >>> .
>>> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en >>> .
>> -- >> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com.
>> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com >> .
>> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en >> .
> -- > You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en > .
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Hey, if you want to plant grass on your carpet, more power to you. If
you ask me to tell you, in my design opinion, the best way to make it
grow, I'm going to advise you against the whole project.
On Sun, May 23, 2010 at 11:47, Drew Miller <e...@anglicangeek.com> wrote:
> And, who does it hurt? This fx is for me, and I don't expect anyone else to
> use it. If I'm wrong, there will be pain and friction in my code and I'll
> change.
> I've never understood why people have strong reactions to trivial or
> inconsequential matters. :)
It's because we programmers are a loving sort, and wish to spare you
that friction and pain. Also, we're opinionated jerks. So you can
pick whichever explanation you like better. :)
Sometimes you just need to do the crazy thing. I get that. Rock on.
Have you considered that this approach means you cannot use
v8::FunctionHandles from C++land as handlers?
--i
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
> Hey, if you want to plant grass on your carpet, more power to you. If
> you ask me to tell you, in my design opinion, the best way to make it
> grow, I'm going to advise you against the whole project.
> On Sun, May 23, 2010 at 11:47, Drew Miller <e...@anglicangeek.com>
> wrote:
>> And, who does it hurt? This fx is for me, and I don't expect anyone
>> else to
>> use it. If I'm wrong, there will be pain and friction in my code
>> and I'll
>> change.
>> I've never understood why people have strong reactions to trivial or
>> inconsequential matters. :)
> It's because we programmers are a loving sort, and wish to spare you
> that friction and pain. Also, we're opinionated jerks. So you can
> pick whichever explanation you like better. :)
> Sometimes you just need to do the crazy thing. I get that. Rock on.
> Have you considered that this approach means you cannot use
> v8::FunctionHandles from C++land as handlers?
> --i
> -- > You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en > .
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
I did not consider that. But, looking at 40 or so handlers in my
application, I don't anticipate that being a scenario I'll encounter.
Thanks for mentioning it though; I'll look into when I might.
Sent from my iPhone
On May 24, 2010, at 12:07 AM, Isaac Schlueter <i...@izs.me> wrote:
> Have you considered that this approach means you cannot use
> v8::FunctionHandles from C++land as handlers?
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
I just re-read that, and it sounded pretty asinine. Sorry.
I don't mean to sound ungrateful. I didn't mention what I as planning to do
initially because I expected this sort of admonition. I intended to just get
the answer to a simple technical question. Then someone asked what I was
wanting to do, and I hate to be dishonest, so I responded when I probably
shouldn't have. Which takes us here.
On the other hand, you brought up one point I hadn't considered, even if it
probably doesn't apply to any app I'd build with my framework. So, thanks
Isaac, for the helpful advice, even if I didn't for it. ;)
On Mon, May 24, 2010 at 12:18 AM, Drew Miller <e...@anglicangeek.com> wrote:
> Of course; I would expect no less than honest and forthright advice, had I
> solicited it. :)
> Sent from my iPhone
> On May 24, 2010, at 12:07 AM, Isaac Schlueter <i...@izs.me> wrote:
> Hey, if you want to plant grass on your carpet, more power to you. If
>> you ask me to tell you, in my design opinion, the best way to make it
>> grow, I'm going to advise you against the whole project.
>> On Sun, May 23, 2010 at 11:47, Drew Miller <e...@anglicangeek.com> wrote:
>>> And, who does it hurt? This fx is for me, and I don't expect anyone else
>>> to
>>> use it. If I'm wrong, there will be pain and friction in my code and I'll
>>> change.
>>> I've never understood why people have strong reactions to trivial or
>>> inconsequential matters. :)
>> It's because we programmers are a loving sort, and wish to spare you
>> that friction and pain. Also, we're opinionated jerks. So you can
>> pick whichever explanation you like better. :)
>> Sometimes you just need to do the crazy thing. I get that. Rock on.
>> Have you considered that this approach means you cannot use
>> v8::FunctionHandles from C++land as handlers?
>> --i
>> --
>> You received this message because you are subscribed to the Google Groups
>> "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com.
>> To unsubscribe from this group, send email to
>> nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
MakeTransfer( { from: 123, to: 456, amount: 789 } );
Python developers have no problem with "named" arguments, and it certainly
makes code more readable than:
MakeTransfer(123, 456, 798);
Maybe it's bad because you depend on arguments' name, but otherwise you
depend on arguments' order... Since JS is not statically typed, there is
even greater chance of messing with arguments...
On Sun, May 23, 2010 at 6:59 PM, Isaac Schlueter <i...@izs.me> wrote:
> Oh, no, Doing It Wrong! Make it stop!
> JavaScript doesn't give you access to the param names precisely
> because this is a terrible idea. The names of the arguments are the
> exclusive domain of the function itself, and not intended to be
> shared. What if there's already some variable called "param" that
> I've closed over, and need access to? What if I'd rather call it "p"
> or "parameter" than "param" because it makes the code more clear?
> You can use function.length to get the number of declared arguments
> (which may not be the number of arguments that it's aware of!), or
> function.name to get the name of the function (or "" if you didn't
> give it one).
> But keying off the argument names is just brittle cleverness of the
> worst sort. Please don't do this terrible thing you're contemplating.
> I *promise* you there's a better way than this madness.
> Position independence and optionality means that you should use a
> single object as the argument. Or, just send everything. Passing an
> object handle to a function is ludicrously cheap, it's not like it has
> to create a whole new object. If you *really* need to specify what's
> going to e passed to the handler, you could do something like this:
> // specify what gets tacked onto the single hash object
> // myHandlerFn({ request : requestObject, session: sessionInfo })
> webFx.handle("route", myHandlerFn, { request : true, session:true })
> // or, specify which args you want, and in which order
> // myHandlerFn(sessionInfo, requestObject)
> webFx.handle("route", myHandlerFn, "session", "request")
> // compare to this one, which gets called like:
> // myOtherHandler(requestObject, sessionInfo, paramList)
> webFx.handle("route", myOtherHandler, "request", "session", "param")
> --i
> On Sun, May 23, 2010 at 00:52, Adam <popz...@gmail.com> wrote:
> > Wouldn't this require you to always use the same argument names for
> > the handle functions? This might become a problem if you want a
> > handler that creates a new handler but still need access to the outer
> > handlers arguments, however this might be a very special case.
> > On May 23, 4:03 am, Drew Miller <e...@anglicangeek.com> wrote:
> >> Nick, this is for binding objects from various sources to HTTP request
> >> handlers based on what is "requested" by the handler via its arguments.
> I
> >> know there are various other ways to do this, many of them perfectly
> >> acceptable (I most often see other folks push stuff onto this with
> call);
> >> they're just not what I want. What I want is to support things like
> this:
> >> webFx.handle("/a/static/path", function(request) { //... }
> >> webFx.handle("a/route/with/:param, function(param) { // I don't need a
> >> request object }
> >> webFx.handle("a/route/with/:param, function(param, request, user) { // I
> >> need the authenticated user }
> >> webFx.handle("a/route/with/:param, function(session, param, user) { // I
> >> want session state, and order shouldn't matter }
> >> webFx.handle("a/route/with/:param, function(session, param, user,
> >> someObjectIRegisteredViaDependyInjection) { // objects can come from
> many
> >> sources }
> >> Again, I know of many ways to provide the means for what I want to do
> here,
> >> but this is the way I want my API. I already have a JavaScript parser
> >> written in JavaScript from another project, so parsing the source of the
> >> handler function is just fine. I was just curious if Node offered
> something
> >> special in this regard (I wasn't expecting it did).
> >> Kris, this will only target Node; I'm not worried about differing
> toString()
> >> behavior on function objects in other engines.
> >> Thanks,
> >> Drew
> >> On Sat, May 22, 2010 at 6:32 PM, Nicholas Campbell <
> >> nicholas.j.campb...@gmail.com> wrote:
> >> > What are you attempting to do with this?
> >> > - Nick
> >> > On May 22, 2010 9:29 PM, "Kris Kowal" <kris.ko...@cixar.com> wrote:
> >> > On Sat, May 22, 2010 at 3:46 PM, Drew Miller <e...@anglicangeek.com>
> wrote:
> >> > > I need to get the argum...
> >> > No. Also, bear in mind that JavaScript engines vary on how toSource a
> >> > function so doing this generally is even harder, and sometimes
> >> > impossible.
> >> > Kris Kowal
> >> > --
> >> > You received this message because you are subscribed to the Google
> Groups
> >> > "nodejs" group.
> >> > To po...
> >> > --
> >> > You received this message because you are subscribed to the Google
> Groups
> >> > "nodejs" group.
> >> > To post to this group, send email to nodejs@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> > nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
> <nodejs%2Bunsubscribe@googlegroups.com<nodejs%252Bunsubscribe@googlegroups. com>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> >> To post to this group, send email to nodejs@googlegroups.com.
> >> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
> .
> >> For more options, visit this group athttp://
> groups.google.com/group/nodejs?hl=en.
> > --
> > You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> > To post to this group, send email to nodejs@googlegroups.com.
> > To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
> .
> > For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Because the first one isn't JavaScript. The second one is.
If you want named position-independent parameters, the way to do that
is by passing an object which contains the relevant keys. It's
lovely.
What you *don't* want, and what python doesn't use, is something like this:
function MakeTransfer (from, to, amount) { ... }
// then, much later...
var myArgs = {from:123, to:456, amount:789}
var argNames = getArgumentNames(MakeTransfer)
MakeTransfer( myArgs[argNames[0]], myArgs[argNames[1]], myArgs[argNames[2]])
There's nothing cute about that. You can put the args in any order
(assuming that getArgumentNames actually *works*, which is a big
assumption), and you save the creation of one object (which is
incredibly cheap anyhow). But in the process, it introduces a lot of
error-prone cleverness.
--i
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
On Mon, May 24, 2010 at 12:34 PM, Isaac Schlueter <i...@izs.me> wrote:
> error-prone cleverness
redundant statement :)
btw, +1 in the "holy hell, don't do it that way" camp. At first glance it
looks like you're saying you'd rather parse a function each call than create
an object each call, which sounds like an overhead-negative equation to me
(also the fact that you wouldn't necessarily have to create the object each
call if it's a repetitive call whose options can be cached up a level or
two). That's not the only reason not to do it, of course, as already
explained by others. Finally, I understand the "this is how I'm gonna do it
anyway so stop trying to tell me not to" mindset as we all do that from time
to time; just chiming in to debate-of-the-day. As Isaac said, rock on (with
your crazy ass self).
If we're going to spend lots of time in a framework, why not freshen it up?
> Starting at ugly code all day is bad for the soul.
Making your code brittle is not really freshening it up. This is one of
those things you think is a good idea today, implement it, and then 6 months
later forget you did it and wonder why some new thing you're doing isn't
working how you expect. It's not something you'd want to release to anyone
else either, even with good documentation on the major gotchas associated
with it: "btw, to anyone using this, make sure you name your function
arguments like this..."... blech.
> someObjectIRegisteredViaDependyInjection) { // objects can come from many
> sources }
For the love of everything holy, just make webFx.handle accept a config
object. Or not :)
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
On Mon, May 24, 2010 at 11:29 AM, Ryan Gahl <ryan.g...@gmail.com> wrote:
> On Mon, May 24, 2010 at 12:34 PM, Isaac Schlueter <i...@izs.me> wrote:
>> error-prone cleverness
> redundant statement :)
Wow; I know we software engineers are prone to false generalizations, but
saying clever === error-prone might be taking things too far. :)
> btw, +1 in the "holy hell, don't do it that way" camp. At first glance it
> looks like you're saying you'd rather parse a function each call than create
> an object each call, which sounds like an overhead-negative equation to me
> (also the fact that you wouldn't necessarily have to create the object each
> call if it's a repetitive call whose options can be cached up a level or
> two). That's not the only reason not to do it, of course, as already
> explained by others. Finally, I understand the "this is how I'm gonna do it
> anyway so stop trying to tell me not to" mindset as we all do that from time
> to time; just chiming in to debate-of-the-day. As Isaac said, rock on (with
> your crazy ass self).
Folks, it's not brittle if I know how I write my handlers. I know that 100%
of the handlers I write will work this way with the current version of Node.
Yes, I understand that this would be a horrible idea of I was trying to
build a generally useful framework. I'm not; I'm building something
that accommodates the app I'm building in a way that *I* like, for *me.* I
considered all of the points (save one) you've made, which is why I didn't
initially say what I'd be doing with the knowledge requested. Cuss, I'd
probably admonish me too, without context.
Oh, and *of course* I'm not parsing it per call. It gets parsed when the
handler is added to the handlers collection.
> If we're going to spend lots of time in a framework, why not freshen it up?
>> Starting at ugly code all day is bad for the soul.
> Making your code brittle is not really freshening it up. This is one of
> those things you think is a good idea today, implement it, and then 6 months
> later forget you did it and wonder why some new thing you're doing isn't
> working how you expect. It's not something you'd want to release to anyone
> else either, even with good documentation on the major gotchas associated
> with it: "btw, to anyone using this, make sure you name your function
> arguments like this..."... blech.
Yes, of course making your code brittle is not freshening it up. Anyone who
asserts otherwise has serious issues. I assert that it's not brittle *for
what I am building.*
I do appreciate what you and Isaac are saying about "I know you think this
is a good idea today, but ..." I just don't agree (as you well know by now).
Maybe in a few months I'll drop back in and let you know if the pain and
friction arrived. I have *absolutely no problem* admitting when I'm wrong.
:)
> webFx.handle("a/route/with/:param, function(param) { // I don't need a
>> request object }
> webFx.handle("a/route/with/:param, function(param, request, user) { // I
>> need the authenticated user }
> webFx.handle("a/route/with/:param, function(session, param, user) { // I
>> want session state, and order shouldn't matter }
> webFx.handle("a/route/with/:param, function(session, param, user,
>> someObjectIRegisteredViaDependyInjection) { // objects can come from many
>> sources }
> For the love of everything holy, just make webFx.handle accept a config
> object. Or not :)
That's what I had, and it hurts my eyes. And, if I'm wrong and this approach
hurts me as you expect it will, I'd go back to my last impl', pushing values
onto this with call. Building this.aValue(callback), even for very expensive
per-request values, performs just as well as the (commonly-held insane)
approach I've settled on. It's just not as pretty.
> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
On Mon, May 24, 2010 at 1:45 PM, Drew Miller <e...@anglicangeek.com> wrote:
> I'm building something that accommodates the app I'm building in a way that
> *I* like, for *me.*
Yeah, we all get that, and at the end of the day that trumps all the
arguments from us hotheads. As Isaac said so eloquently, we programmers are
opinionated jerks (btw, Isaac, loved that bit). And I get the "it's not
brittle for me because I'm going to remember that this is there forever and
ever, amen" argument as well. For some things, that's just true, or remains
true for as long as it matters. I guess we're just saying that this falls
within the _class_ of things that most would consider brittle because there
is at least _some_ chance that you or someone else using it could forget the
special rules and as you put it, cause friction and pain. Doing it the
config object way simply removes that possibility, thus is less brittle as a
general approach.
-ryan
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
On Mon, May 24, 2010 at 12:10 PM, Ryan Gahl <ryan.g...@gmail.com> wrote:
> On Mon, May 24, 2010 at 1:45 PM, Drew Miller <e...@anglicangeek.com> wrote:
>> I'm building something that accommodates the app I'm building in a way
>> that *I* like, for *me.*
> Yeah, we all get that, and at the end of the day that trumps all the
> arguments from us hotheads. As Isaac said so eloquently, we programmers are
> opinionated jerks (btw, Isaac, loved that bit). And I get the "it's not
> brittle for me because I'm going to remember that this is there forever and
> ever, amen" argument as well. For some things, that's just true, or remains
> true for as long as it matters. I guess we're just saying that this falls
> within the _class_ of things that most would consider brittle because there
> is at least _some_ chance that you or someone else using it could forget the
> special rules and as you put it, cause friction and pain. Doing it the
> config object way simply removes that possibility, thus is less brittle as a
> general approach.
> -ryan
> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com<nodejs%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Hate to continue flaming this but, you know, i kinda have to :P
JavaScript doesn't have this level of introspection and that is
intentional it's not an oversight or a bug.
Don't build APIs that depend on features a language doesn't have, it's
a very bad practice. Write an API for JavaScript the way JavaScript
supports it, not something that looks like Python/Ruby.
On Mon, May 24, 2010 at 12:15 PM, Drew Miller <e...@anglicangeek.com> wrote:
> Agreed. And, I certainly empathize with being an opinionated jerk; were I
> not one, I'd have let this go several posts ago. :)
> On Mon, May 24, 2010 at 12:10 PM, Ryan Gahl <ryan.g...@gmail.com> wrote:
>> On Mon, May 24, 2010 at 1:45 PM, Drew Miller <e...@anglicangeek.com> wrote:
>>> I'm building something that accommodates the app I'm building in a way
>>> that *I* like, for *me.*
>> Yeah, we all get that, and at the end of the day that trumps all the
>> arguments from us hotheads. As Isaac said so eloquently, we programmers are
>> opinionated jerks (btw, Isaac, loved that bit). And I get the "it's not
>> brittle for me because I'm going to remember that this is there forever and
>> ever, amen" argument as well. For some things, that's just true, or remains
>> true for as long as it matters. I guess we're just saying that this falls
>> within the _class_ of things that most would consider brittle because there
>> is at least _some_ chance that you or someone else using it could forget the
>> special rules and as you put it, cause friction and pain. Doing it the
>> config object way simply removes that possibility, thus is less brittle as a
>> general approach.
>> -ryan
>> --
>> You received this message because you are subscribed to the Google Groups
>> "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com.
>> To unsubscribe from this group, send email to
>> nodejs+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
-- You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com.
To unsubscribe from this group, send email to nodejs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
