2009/10/21 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,
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
On Oct 21, 2009, at 8:47, Izidor Jerebic wrote:
>
>
> On 21.10.2009, at 16:40, Robert Kieffer wrote:
>
>> Or to put it anoth
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 capit
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 assign
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
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
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,
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
Extends your Prototype, the Force does, mnn...
---
Warm Regards,
Ryan Gahl
On Fri, Oct 16, 2009 at 4:48 PM, joneff wrote:
>
> (off topic, or would it be "May the Force extends your.prototype"?)
> >
>
--~--~-~--~~~---~--~~
You received this message because
(off topic, or would it be "May the Force extends your.prototype"?)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsu
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 ma
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 Fu
On Oct 16, 9:14 am, Ryan Gahl wrote:
> Are you sure not Function.eMpTy ?
Would the order of capitalization be based on phase of the moon?
[...]
--
kangax
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype:
Are you sure not Function.eMpTy ?
:P
---
Warm Regards,
Ryan Gahl
On Fri, Oct 16, 2009 at 6:15 AM, Joran Greef wrote:
>
> "Function.IDENTITY and Function.EMPTY are never called directly,
> though. They're canonical functions."
>
> Agreed. Hence, Function.reference instead of Function.empty.
>
"Function.IDENTITY and Function.EMPTY are never called directly,
though. They're canonical functions."
Agreed. Hence, Function.reference instead of Function.empty.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Pro
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
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 face
Hey Andrew,
Aren't all functions constants, in that sense? Function.EMPTY isn't
more or less constant than Element.extend.
-- T.J. ;-)
On Oct 15, 1:08 am, Andrew Dupont wrote:
> Weighing in again, decades after starting the thread.
>
> First, I'm fine with calling it Function.IDENTITY instead
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
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 Func
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.
--~--~-~--~~~---~--~~
You received this message be
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 threa
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.
Well, it *could* do:
Function.empty = function(){};
Function.empty.empty = f
2009/9/29 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.
> >
>
Numpty brain this morning, but ...
As I understand things, K(x) => x, not K(x) => (fn() => x)
--
Prototype's existing String.empty and Array.empty interfaces would
imply that Function.empty return a boolean indicating perhaps that the
function is empty.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype:
On Sep 28, 3:44 am, Jim Higson wrote:
> On Saturday 26 September 2009 04:04:22 kangax wrote:
>
>
>
> > On Sep 24, 11:20 pm, 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
> > > `Proto
On Saturday 26 September 2009 04:04:22 kangax wrote:
> On Sep 24, 11:20 pm, 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
Ah, i forgot that i used even more overkilling but working solution:
element.observe('selectstart', Event.stop);
Anyway i got your point.
On Sat, 26 Sep 2009 19:10:34 +0400, kangax wrote:
>
>
>
> On Sep 26, 6:30 am, "artemy tregubenko" wrote:
>> Why don't you use element.onselectstart = Eve
On Sep 26, 6:30 am, "artemy tregubenko" 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 propert
Why don't you use element.onselectstart = Event.stop; ?
On Sat, 26 Sep 2009 07:04:22 +0400, kangax wrote:
> onselectstart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this
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 be
On Sep 24, 11:20 pm, 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,
+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.
--~--~-~--~~~---~--~~
You
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.
On Sep 25, 3:11 pm, Robert Kieffer wrote:
> Function.empty and Function.identity get my vote.
>
> Howev
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
We could _so_ overcomplicate this... ;-)
On Sep 25, 1:29 pm, Jim Higson 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
>
> >
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(
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
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
On Fri, Sep 25, 2009 at 6:22 AM, T.J. Crowder wrote:
>
>> Hmm, whilst technically correct, the term "identity" may not be what
>> people are used to.
>
> Goo
> 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 wrote:
> 2009/9/25 T.J. Crowder :
>
>
>
>
>
>
>
> > Andrew,
>
>
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 i
2009/9/25 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.
>
> On Sep 25, 4:20 am, Andrew Dupont wrote:
>> Unless anyone has serious objectio
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 wrote:
> Unless anyone has serious objections, or has a better idea, I'm going
> to ad
43 matches
Mail list logo
