Unless anyone has serious objections, or has a better idea, I'm going
to add these as aliases of `Prototype.emptyFunction` and
`Prototype.K`, respectively. They belong better there, since in theory
the `Prototype` namespace is for internal stuff, not for stuff that
has value to end-user developers.
Make sense. Shouldn't that be Function.empty and Function.k, though,
to follow our naming rules? And perhaps Function.k should have a more
meaningful name.
-- T.J.
On Sep 25, 4:20 am, Andrew Dupont <goo...@andrewdupont.net> wrote:
> Unless anyone has serious objections, or has a better idea, I'm going
> to add these as aliases of `Prototype.emptyFunction` and
> `Prototype.K`, respectively. They belong better there, since in theory
> the `Prototype` namespace is for internal stuff, not for stuff that
> has value to end-user developers.
> Make sense. Shouldn't that be Function.empty and Function.k, though,
> to follow our naming rules? And perhaps Function.k should have a more
> meaningful name.
> -- T.J.
> On Sep 25, 4:20 am, Andrew Dupont <goo...@andrewdupont.net> wrote:
>> Unless anyone has serious objections, or has a better idea, I'm going
>> to add these as aliases of `Prototype.emptyFunction` and
>> `Prototype.K`, respectively. They belong better there, since in theory
>> the `Prototype` namespace is for internal stuff, not for stuff that
>> has value to end-user developers.
>> Cheers,
>> Andrew
As f(x) => x, f is an identity function.
So, maybe
Function.identity(x) { return x; }
Hmm, whilst technically correct, the term "identity" may not be what
people are used to.
On Friday 25 September 2009 04:20:06 Andrew Dupont wrote:
> Unless anyone has serious objections, or has a better idea, I'm going > to add these as aliases of `Prototype.emptyFunction` and > `Prototype.K`, respectively. They belong better there, since in theory > the `Prototype` namespace is for internal stuff, not for stuff that > has value to end-user developers.
That's quite odd actually, on the bus from London to Oxford this morning I was wondering if they should be named this way in Prototype. But, yes, I have been doing it this way for quite some time in my own projects. I think it is much more intuitive.
I would probably use Function.IDENTITY rather than Function.K because probably more people are familiar with 'the identity function' than 'k'.
> 2009/9/25 T.J. Crowder <t...@crowdersoftware.com>:
> > Andrew,
> > Make sense. Shouldn't that be Function.empty and Function.k, though,
> > to follow our naming rules? And perhaps Function.k should have a more
> > meaningful name.
> > -- T.J.
> > On Sep 25, 4:20 am, Andrew Dupont <goo...@andrewdupont.net> wrote:
> >> Unless anyone has serious objections, or has a better idea, I'm going
> >> to add these as aliases of `Prototype.emptyFunction` and
> >> `Prototype.K`, respectively. They belong better there, since in theory
> >> the `Prototype` namespace is for internal stuff, not for stuff that
> >> has value to end-user developers.
> >> Cheers,
> >> Andrew
> As f(x) => x, f is an identity function.
> So, maybe
> Function.identity(x) { return x; }
> Hmm, whilst technically correct, the term "identity" may not be what
> people are used to.
On Fri, Sep 25, 2009 at 6:22 AM, T.J. Crowder <t...@crowdersoftware.com> wrote:
>> Hmm, whilst technically correct, the term "identity" may not be what
>> people are used to.
> Good point about it being an identity function, but agreed about
> confusion.
> "passThrough"?
> -- T.J.
> On Sep 25, 8:47 am, Richard Quadling <rquadl...@googlemail.com> wrote:
>> 2009/9/25 T.J. Crowder <t...@crowdersoftware.com>:
>> > Andrew,
>> > Make sense. Shouldn't that be Function.empty and Function.k, though,
>> > to follow our naming rules? And perhaps Function.k should have a more
>> > meaningful name.
>> > -- T.J.
>> > On Sep 25, 4:20 am, Andrew Dupont <goo...@andrewdupont.net> wrote:
>> >> Unless anyone has serious objections, or has a better idea, I'm going
>> >> to add these as aliases of `Prototype.emptyFunction` and
>> >> `Prototype.K`, respectively. They belong better there, since in theory
>> >> the `Prototype` namespace is for internal stuff, not for stuff that
>> >> has value to end-user developers.
>> >> Cheers,
>> >> Andrew
>> As f(x) => x, f is an identity function.
>> So, maybe
>> Function.identity(x) { return x; }
>> Hmm, whilst technically correct, the term "identity" may not be what
>> people are used to.
On the subject of end developer confusion, I'd like to make a suggestion regarding the naming...
Function.emptyFn Function.returnFn
Because they say exactly what they are. This is how I've named (almost... $.function.emptyFn() and $.function.returnFn() ) the exact same functionality in the Pollen.JS library (for use within a new Worker() )
On Friday 25 September 2009 13:08:57 Rick Waldron wrote:
> On the subject of end developer confusion, I'd like to make a suggestion > regarding the naming...
> Function.emptyFn > Function.returnFn
> Because they say exactly what they are. This is how I've named (almost... > $.function.emptyFn() and $.function.returnFn() ) the exact same > functionality in the Pollen.JS library (for use within a new Worker() )
I'd say returnFn sounds like a function which returns a function.
> On Friday 25 September 2009 13:08:57 Rick Waldron wrote:
> > On the subject of end developer confusion, I'd like to make a suggestion
> > regarding the naming...
> > Function.emptyFn
> > Function.returnFn
> > Because they say exactly what they are. This is how I've named (almost...
> > $.function.emptyFn() and $.function.returnFn() ) the exact same
> > functionality in the Pollen.JS library (for use within a new Worker() )
> I'd say returnFn sounds like a function which returns a function.
However, does this mean Prototype.EMPTY and Prototype.K are being
deprecated? I ask because I generally dislike aliases in APIs. Unless they
are used as part of the deprecation process, they are usually more trouble
than they're worth. They make code harder to read and share, developers get
into silly quibbles as to which is better, etc. In short, they're annoying
- it's better if the framework developers make it clear what the preferred
name is, and eventually deprecate the non-preferred ones.
My $.02.
- rwk
On Fri, Sep 25, 2009 at 6:19 AM, T.J. Crowder <t...@crowdersoftware.com>wrote:
> On Sep 25, 1:29 pm, Jim Higson <j...@wikizzle.org> wrote:
> > On Friday 25 September 2009 13:08:57 Rick Waldron wrote:
> > > On the subject of end developer confusion, I'd like to make a
> suggestion
> > > regarding the naming...
> > > Function.emptyFn
> > > Function.returnFn
> > > Because they say exactly what they are. This is how I've named
> (almost...
> > > $.function.emptyFn() and $.function.returnFn() ) the exact same
> > > functionality in the Pollen.JS library (for use within a new Worker() )
> > I'd say returnFn sounds like a function which returns a function.
> Function.empty and Function.identity get my vote.
> However, does this mean Prototype.EMPTY and Prototype.K are being
> deprecated? I ask because I generally dislike aliases in APIs. Unless they
> are used as part of the deprecation process, they are usually more trouble
> than they're worth. They make code harder to read and share, developers get
> into silly quibbles as to which is better, etc. In short, they're annoying
> - it's better if the framework developers make it clear what the preferred
> name is, and eventually deprecate the non-preferred ones.
> My $.02.
> - rwk
> On Fri, Sep 25, 2009 at 6:19 AM, T.J. Crowder <t...@crowdersoftware.com>wrote:
> > We could _so_ overcomplicate this... ;-)
> > On Sep 25, 1:29 pm, Jim Higson <j...@wikizzle.org> wrote:
> > > On Friday 25 September 2009 13:08:57 Rick Waldron wrote:
> > > > On the subject of end developer confusion, I'd like to make a
> > suggestion
> > > > regarding the naming...
> > > > Because they say exactly what they are. This is how I've named
> > (almost...
> > > > $.function.emptyFn() and $.function.returnFn() ) the exact same
> > > > functionality in the Pollen.JS library (for use within a new Worker() )
> > > I'd say returnFn sounds like a function which returns a function.
+1 to Function.identity
+1 to deprecating Prototype.emptyFunction and Prototype.K
I prefer Function.reference to Function.empty. String.empty already
exists but not as reference to an empty string. Function.reference
describes the intent.
On Sep 24, 11:20 pm, Andrew Dupont <goo...@andrewdupont.net> wrote:
> Unless anyone has serious objections, or has a better idea, I'm going
> to add these as aliases of `Prototype.emptyFunction` and
> `Prototype.K`, respectively. They belong better there, since in theory
> the `Prototype` namespace is for internal stuff, not for stuff that
> has value to end-user developers.
It sure makes more sense to have those on `Function`. I kind of hate
that we're putting yet another (completely made-up) method on yet
another built-in native, but it looks like there's not much that can
be done about it at this point anyway.
As far as naming, I would probably go with `Function.empty` and
`Function.identity` (`Function.K` looks neat but it would then make
sense to uppercase `EMPTY` too, and I like lowercase version more).
Now that we're on this subject, we can also add so often useful
`Function.false` (i.e. `function(){ return false; }`). I use it all
the time for things like preventing events -
`someElement.onselectstart = Prototype.falseFunction;`, etc.
Actually I use Function.preventDefault = function(callback, e)
{ callback(e); e.preventDefault() }; witch is excaclly for event
handing, but I think there isn't any chance this could go into core.
As for Fuction.empty / Function.identity +1 ( at first identity
sounded weird, but I could find a better name my self )
On Sep 26, 6:30 am, "artemy tregubenko" <m...@arty.name> wrote:
> Why don't you use element.onselectstart = Event.stop; ?
Because `Event.stop` expects first argument to be an event object, and
MSHTML does not supply that argument to event handler attached as a
property of an element. When assigned to a property, `Event.stop` will
try to operate on an undefined value and eventually throw error.
Even if `Event.stop` accounted for IE-proprietary `window.event`, it
would be kind of an overkill to 1) extend event, 2) prevent its
default action, 3) stop propagation, and 4) extend it with "stopped"
property - when all that's needed is plain and simple - `return
false`.
On Sat, 26 Sep 2009 19:10:34 +0400, kangax <kan...@gmail.com> wrote:
> On Sep 26, 6:30 am, "artemy tregubenko" <m...@arty.name> wrote:
>> Why don't you use element.onselectstart = Event.stop; ?
> Because `Event.stop` expects first argument to be an event object, and
> MSHTML does not supply that argument to event handler attached as a
> property of an element. When assigned to a property, `Event.stop` will
> try to operate on an undefined value and eventually throw error.
> Even if `Event.stop` accounted for IE-proprietary `window.event`, it
> would be kind of an overkill to 1) extend event, 2) prevent its
> default action, 3) stop propagation, and 4) extend it with "stopped"
> property - when all that's needed is plain and simple - `return
> false`.
> On Sep 24, 11:20 pm, Andrew Dupont <goo...@andrewdupont.net> wrote: > > Unless anyone has serious objections, or has a better idea, I'm going > > to add these as aliases of `Prototype.emptyFunction` and > > `Prototype.K`, respectively. They belong better there, since in theory > > the `Prototype` namespace is for internal stuff, not for stuff that > > has value to end-user developers.
> It sure makes more sense to have those on `Function`. I kind of hate > that we're putting yet another (completely made-up) method on yet > another built-in native, but it looks like there's not much that can > be done about it at this point anyway.
> As far as naming, I would probably go with `Function.empty` and > `Function.identity` (`Function.K` looks neat but it would then make > sense to uppercase `EMPTY` too, and I like lowercase version more).
> Now that we're on this subject, we can also add so often useful > `Function.false` (i.e. `function(){ return false; }`). I use it all > the time for things like preventing events - > `someElement.onselectstart = Prototype.falseFunction;`, etc.
> Is anyone else using something like that?
I have Function.alwaysReturn( val );
So, I'd use Function.alwaysReturn( false ) in that case.
Is good for anywhere a function is expected but you want to insert a value. Eg, Function.alwaysReturn( 4 );
Function.alwaysReturn = function ( val ){ return (function(){return val}); };
> On Saturday 26 September 2009 04:04:22 kangax wrote:
> > On Sep 24, 11:20 pm, Andrew Dupont <goo...@andrewdupont.net> wrote:
> > > Unless anyone has serious objections, or has a better idea, I'm going
> > > to add these as aliases of `Prototype.emptyFunction` and
> > > `Prototype.K`, respectively. They belong better there, since in theory
> > > the `Prototype` namespace is for internal stuff, not for stuff that
> > > has value to end-user developers.
> > It sure makes more sense to have those on `Function`. I kind of hate
> > that we're putting yet another (completely made-up) method on yet
> > another built-in native, but it looks like there's not much that can
> > be done about it at this point anyway.
> > As far as naming, I would probably go with `Function.empty` and
> > `Function.identity` (`Function.K` looks neat but it would then make
> > sense to uppercase `EMPTY` too, and I like lowercase version more).
> > Now that we're on this subject, we can also add so often useful
> > `Function.false` (i.e. `function(){ return false; }`). I use it all
> > the time for things like preventing events -
> > `someElement.onselectstart = Prototype.falseFunction;`, etc.
> > Is anyone else using something like that?
> I have Function.alwaysReturn( val );
> So, I'd use Function.alwaysReturn( false ) in that case.
> Is good for anywhere a function is expected but you want to insert a value.
> Eg, Function.alwaysReturn( 4 );
> Function.alwaysReturn =
> function ( val ){
> return (function(){return val});
> };
I remember seeing this in Dean's base2.js and Oliver Steele's
functional.js under then name - "K":
function K(value){
return function() {
return value;
}
}
It's then easy to define other abstractions with this one function -
Prototype's existing String.empty and Array.empty interfaces would
imply that Function.empty return a boolean indicating perhaps that the
function is empty.
> Prototype's existing String.empty and Array.empty interfaces would
> imply that Function.empty return a boolean indicating perhaps that the
> function is empty.
Numpty brain this morning, but ...
As I understand things, K(x) => x, not K(x) => (fn() => x)
On Tuesday 29 September 2009 06:49:15 Joran Greef wrote:
> Prototype's existing String.empty and Array.empty interfaces would > imply that Function.empty return a boolean indicating perhaps that the > function is empty.
Being serious for a moment, it sounds like we're all happy (enough)
with Function.empty.
Can't say I *like* Function.identity (I'd prefer "Function.passBack")
but it at least is readily defensible as being derived from
mathematics (like curry) and there are several "yea" vote for it in
this thread.
-- T.J. :-)
On Sep 29, 8:58 am, Jim Higson <j...@wikizzle.org> wrote:
> On Tuesday 29 September 2009 06:49:15 Joran Greef wrote:
> > Prototype's existing String.empty and Array.empty interfaces would
> > imply that Function.empty return a boolean indicating perhaps that the
> > function is empty.
Agreed. I like Function.identity as well for the same reason in that
there is in fact a reason. I don't think Function.empty has the same
going for it, apart from it being the legacy terminology. We could do
better.
Weighing in again, decades after starting the thread.
First, I'm fine with calling it Function.IDENTITY instead of Function.K.
On Sep 25, 2009, at 1:26 AM, T.J. Crowder wrote:
> Make sense. Shouldn't that be Function.empty and Function.k, though, > to follow our naming rules? And perhaps Function.k should have a more > meaningful name.
I'm very much in favor of all-caps, or at least initial caps, to indicate that these are constants. We don't do this consistently in the framework so far, but I'd like it to match stuff like Event.KEY_ESC. I think the capitalization will also help distinguish it from String#empty and Array#empty, as was mentioned elsewhere. (Aside: I'm also in favor of renaming those methods to `isEmpty` for 2.0.)
|
