Function.EMPTY and Function.K

[Andrew Dupont]

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

[T.J. Crowder]

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.

[Richard Quadling]

2009/9/25 T.J. Crowder <t...@crowdersoftware.com>:

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.

Maybe Function.AsIs() ?

--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

[Jim Higson]

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'.

--
Jim
my wiki ajaxification thing: http://wikizzle.org
my blog: http://jimhigson.blogspot.com/

[T.J. Crowder]

> 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.

[Allen Madsen]

I think Function.identity is fine. If somebody is unsure of what it it
they can check the docs.

Allen Madsen
http://www.allenmadsen.com

[Rick Waldron]

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() )


Rick

[Jim Higson]

I'd say returnFn sounds like a function which returns a function.

[T.J. Crowder]

We could _so_ overcomplicate this... ;-)

[Robert Kieffer]

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

[T.J. Crowder]

Well, technically they aren't part of the API because the Prototype
namespace isn't public (in theory), but:

+1 to the new ones
+1 to deprecating and ultimately removing the old ones

-- T.J.

[Joran]

+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.

[kangax]

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?

--
kangax

[Radoslav Stankov]

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 )

[artemy tregubenko]

Why don't you use element.onselectstart = Event.stop; ?

On Sat, 26 Sep 2009 07:04:22 +0400, kangax <kan...@gmail.com> wrote:

> onselectstart

[kangax]

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`.

[...]

--
kangax

[artemy tregubenko]

Ah, i forgot that i used even more overkilling but working solution:
element.observe('selectstart', Event.stop);

Anyway i got your point.

[Jim Higson]

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});
};

[kangax]

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 -

Function.empty = K();
Function.false = K(false);
Function.true = K(true);

// etc.

--
kangax

[Joran Greef]

Prototype's existing String.empty and Array.empty interfaces would
imply that Function.empty return a boolean indicating perhaps that the
function is empty.

[Richard Quadling]

2009/9/29 Joran Greef <joran...@gmail.com>:

>
> 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)

[Jim Higson]

Well, it *could* do:

Function.empty = function(){};
Function.empty.empty = function(){return true};

Of course this doesn't cover other empty functions and I may be not entirely
serious ;-)

Jim

[T.J. Crowder]

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. :-)

[Joran Greef]

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.

[Andrew Dupont]

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.)

What do people think about the capitalization?

Cheers,
Andrew

[Jim Higson]

On Thursday 15 October 2009 01:08:53 Andrew Dupont wrote:
> 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.

Aren't most functions 'constants'?
Eg, Array.empty isn't supposed to be reassigned but we don't write Array.EMPTY

> 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.)
>
> What do people think about the capitalization?
>
> Cheers,
> Andrew
>
>
>

[T.J. Crowder]

Hey Andrew,

Aren't all functions constants, in that sense? Function.EMPTY isn't
more or less constant than Element.extend.

-- T.J. ;-)

[Ryan Gahl]

Guys... (tapping shoulder)... um.... this is some pretty inconsequential stuff that's being debated, wouldn't you say?

Just do Function.empty = Function.EMPTY = function() {};

(or just pick one)

Sorry, it really just doesn't matter vs. file size, modularity, performance, features, (17 other facets I can't think of right now...).

---
Warm Regards,
Ryan Gahl

[Andrew Dupont]

On Oct 15, 2009, at 4:22 AM, T.J. Crowder wrote:

>
> Hey Andrew,
>
> Aren't all functions constants, in that sense? Function.EMPTY isn't
> more or less constant than Element.extend.

Function.IDENTITY and Function.EMPTY are never called directly,
though. They're canonical functions.

Meh, if I'm the only one who thinks of them that way, I'll shut up.
But I want to hear from more people.

Cheers,
Andrew

[Joran Greef]

"Function.IDENTITY and Function.EMPTY are never called directly,
though. They're canonical functions."

Agreed. Hence, Function.reference instead of Function.empty.

[Ryan Gahl]

Are you sure not Function.eMpTy ?

:P

---
Warm Regards,
Ryan Gahl

[kangax]

On Oct 16, 9:14 am, Ryan Gahl <ryan.g...@gmail.com> wrote:
> Are you sure not Function.eMpTy ?

Would the order of capitalization be based on phase of the moon?

[...]

--
kangax

[Tobie Langel]

Hi, Andrew.

As previously mentioned, K is ambiguous, as it can mean both:

function K(arg) { return arg; }

or:

function K(arg) { return function() { return arg; }; }

depending on your reference (Tcl for the former, combinatory logic for
the latter).

My vote therefore goes for using Function.IDENTITY.

I'm also strongly in favor of using uppercase for constant-like
objects. Given the language, this is of course purely conventional
(much like the underscore prefix for private methods). It's a very
useful nonetheless.

Best,

Tobie

[Иван Жеков]

Don't get me wrong, but we are not talking about splitting the core of the atom in 16 different particles. Instead the topic of discussion is how to name (and where to place) the empty and identity function.

Two things should be taken into account -- common sense and consistency.

Deriving from mathematics, how is this function called -- f(x) = x, for every instance of x? Identity function. That's a the perfect name (as mentioned above).

And since this is not a constant function, no need to be capitalized. And since JS is generally camel case, first letter stays lowercase.

The place to put it? The Function object. Hence, Function#identity

Now apply the consistency and you get Function#empty

Simple as that.


Or use purely statistical approach:

If anyone bothered to sum up this elaborate discussion the result would be:

1) Prototype#emptyFunction and Prototype#K are considered / approved / you name it for deprecation by the majority of people who post here

2) Function#empty (and caps) and Function#identity (and caps) are considered / approved / you name it for addition by the majority of the people who post here.

Logical outcome -- if the core developers haven't decided yet whether or not to use caps, make a poll (if you feel like to it), or use any random way to determine the value of a boolean (0 for small caps, 1 for caps) -- get wasted, ask a stranger, wait for 2012.

My apologies if I am rude in my words, but it's either commons sense, or toss a coin (observe the moon phase etc).

*** A bit off topic ***

The real issue to me is consistency. While many of you noted that Prototype was born of adapting ruby-like syntax for Java Script, I prefer it because it's much closer to actual programming than some JS libraries and is not as complicated as other libraries.

However, due to incompatibility of syntax between ruby and JS (string#empty? per say) changes in the core (Language extension part) must made. The best place to look for inspiration would be other ECMA standardized languages / dialect, such as Action Script (the closes dialect to JavaScript there is) or C# (not so close, but still in the vicinity of close syntax).

*** End of off topic ***

Again, two key components -- consistency and common sense.

May the Force.prototype extends you.

-- joneff

[joneff]

(off topic, or would it be "May the Force extends your.prototype"?)

[Ryan Gahl]

Extends your Prototype, the Force does, mnnmmmm...

---
Warm Regards,
Ryan Gahl

[Izidor Jerebic]

On 16.10.2009, at 23:45, Иван Жеков wrote:

> Don't get me wrong, but we are not talking about splitting the core
> of the atom in 16 different particles. Instead the topic of
> discussion is how to name (and where to place) the empty and
> identity function.
>
> Two things should be taken into account -- common sense and
> consistency.
>
> Deriving from mathematics, how is this function called -- f(x) = x,
> for every instance of x? Identity function. That's a the perfect
> name (as mentioned above).
>
> And since this is not a constant function, no need to be
> capitalized. And since JS is generally camel case, first letter
> stays lowercase.

I beg to differ. IDENTITY is constant in function value space
similarly as PI is constant in floating point value space. There is
only one IDENTITY and only one PI...

This calls for all-upper-case, similarly for K (or whatever it is
called)...

izidor

[joneff]

I fail to see how is identity considered constant.

To me succ and pred are ideologically similar to identity (where as
they return successor / predecessor of the input argument), and from
your point of view they should also be constant since there is only
one succ and one pred function. Actually, from your point of view each
unique function (a function that returns different result for
different argument) should be considered constant function since there
is only one way to get the result.

Also, I found this example in my (quite old) "learn c" book under
"defining functions and constants"

#define PI 3.14159
#define pred(x) ((x)-1)

which further proves my point.

To me a constant function is f(x) = x^0, since it's always equal to 1.

-- joneff

[Izidor Jerebic]

On 21.10.2009, at 14:38, joneff wrote:

> Actually, from your point of view each
> unique function (a function that returns different result for
> different argument) should be considered constant function since there
> is only one way to get the result.

This is true. Value of a function 'f' is not its return value (there
is none without parameter), but the code which defines its behaviour.
You can do alert( f ) to see how javascript treats function values.

>
> To me a constant function is f(x) = x^0, since it's always equal to 1.

This is a function which returns constant value (constant in space of
floating point values). The return value is not the value of function
in function space, the value in function space is the code which
defines its behaviour. And in this space IDENTITY is constant - there
is only one.

alert( Funtion.IDENTITY ) shows you the value, and this value is
constant in space of function values. This is one special function
value - it corresponds to function which returns its parameter, and
because of that this constant value deserves a name (unlike other
constant function values, for which we do not have a name).


izidor

[Robert Kieffer]

Izador, by your logic shouldn't all static methods should be up-cased -  Math.random, String.fromCharCode, Date.now, etc? They are all unique and, for all intents and purposes, canonical.

Or to put it another way, what is the difference between "f(x) = x" and "f(x) = x+1"... why would the former be up-cased, but not the latter?

My vote goes to lower-case.  It's easier to type, and I don't see enough of a distinction to warrant special casing.

- rwk

[Izidor Jerebic]

On 21.10.2009, at 16:40, Robert Kieffer wrote:

> Or to put it another way, what is the difference between "f(x) = x"
> and "f(x) = x+1"... why would the former be up-cased, but not the
> latter?

Ours already has a name in mathematics - identity function, and it is
primarily used by assigning its value (like var f =
Function.IDENTITY), not by calling it (like Function.IDENTITY(3); )

We want this value to be assigned or passed as parameter. That is the
main purpose of the definition. Our interest in other functions is
primarily in calling them - you rarely assign Math.random.

So the difference is in usage - is it used more as value or more as
function call ? If it is value, then it is treated as constant (which
it is). If it is called, it is treated as function name.

IDENTITY is obviously never meant to be called explicitly, so it is a
constant value meant to be passed around.

izidor

[Bob Kerns]

That is true of ALL functions in Prototype. Therefore they should all
be capitalized.

Really, this comes up because in js there is no separation between the
function name space and the value namespace. (Or the class/type
namespace ...).

I suggest resolving it by saying no function is capitalized. But that
is incompatible. So I suggest instead that no NEW functions are
capitalized.

That means that constants are capitalized, unless they are functions,
unless they are one of the small existing set of capitalized functions.

I think that is the best you can do, consistency-wise.

Sent from my iPhone

[Bob Kerns]

The problem I have with this boundary is that it is blurry. Every
function can be passed around, and in functional programming styles,
often are.

Sent from my iPhone

[Richard Quadling]

2009/10/21 Izidor Jerebic <ij....@gmail.com>:

http://en.wikipedia.org/wiki/Constant_function vs
http://en.wikipedia.org/wiki/Identity_function

I don't see identity() as a constant function.

A function which returns your DOB would be a constant function.

In some ways..

define('DOB', '1967/10/01');

would be the same as ...

function DOB(){
returns '1967/10/01';
}

In both cases, it is the value that has to remain constant.