[Proto-Scripty] Re: Adding properties to native objects
Hi Joe,
T.J.'s factory suggestion...
FWIW, I think it was Doug's suggestion, I just updated it a bit.
function DateFactory(){
var fName, that = new Date();
for (fName in SpecialDateProps)
that[fName] = SpecialDateProps[fName](); // Note calling the
fName's function.
return that;
}
I'm not immediately seeing how that works. There are two problems I
see:
1. When you're calling the functions, they don't have any context to
work with. How do they know what date they're meant to be working on?
2. Date instances are mutable, but you're setting a flag on the date
just once at creation time. So even if the flag is correct at the
time the instance is created, it can be made incorrect by using any of
the mutator functions (setMonth, etc.).
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On May 20, 9:14 pm, joe t. thooke...@gmail.com wrote:
One last note barring any huge revelations:
T.J.'s factory suggestion was almost exactly right. His code as-is
adds the methods to my customized Date. However, since i want
properties of the same name that receive the return values of those
methods, i MUST use the non-Object#extend version, as such:
var SpecialDateProps = {
isEaster:function(){ return ... },
etc.};
function DateFactory(){
var fName, that = new Date();
for (fName in SpecialDateProps)
that[fName] = SpecialDateProps[fName](); // Note calling the
fName's function.
return that;
}
Thanks again!
-joe t.
On May 20, 1:12 pm, joe t. thooke...@gmail.com wrote:
T.J.,
i think my last post was at least somewhat in line with your
suggestion. i just hadn't fully read and absorbed yours yet.
i will try using that factory approach. If i'm reading it right, it
handles the two-line requirement of creating the native Date, then
calling the ApplySpecialProps method.
As always, thanks for the help!
-joe
On May 20, 12:23 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Heya,
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
The problem with that as written is that it creates separate isEaster
and isLaborDay functions for every single instance you create, each of
which eats memory:
var a = specialDateFactory();
var b = specialDateFactory();
alert(a.isEaster === b.isEaster); // false
You can avoid that:
var MoreDateFunctions = {
isEaster: function () {return ...},
isLaborDay: function () {return ...}};
function specialDateFactory() {
return Object.extend(new Date(), MoreDateFunctions);
// Or, without Prototype's Object.extend:
// var fname, that;
// that = new Date();
// for (fname in MoreDateFunctions) {
// that[fname] = MoreDateFunctions[fname];
// }
// return that;
}
...but I'm not seeing much benefit at that point. I suppose it means
you haven't modified the Date prototype.
(BTW: Anyone tempted to create an ExtendedDate object using a Date
object as its prototype, think again, for some reason the spec
specifically disallows it in Section 15.9.5, and Firefox [and probably
others] implements the limitation.)
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On May 20, 4:07 pm, P. Douglas Reeder reeder...@gmail.com wrote:
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
You can get more sophisticated - creating a prototype object for
special dates, with the functions defined on it, and using closures to
protect it, but I can't write that off the top of my head...
On May 20, 7:50 am, ColinFine colin.f...@pace.com wrote:
On May 20, 12:16 am, RobG rg...@iinet.net.au wrote:
On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote:
This is a case when you really truly want just the facilities that
Javascript provides (prototypes rather than classes), and using
(pretend) classes makes it harder not easier.
Yes, although some may argue that it is better to create a new
object
that has the required methods and leverages the methods of Date,
rather than modifying a built-in object prototype,
Fair comment. But you are still talking about using Javascript's
prototype, rather than inventing classes. That was my point.
(I wouldn't have made this remark before I read Crockford's
Javascript: The Good Parts -
[Proto-Scripty] Re: Adding properties to native objects
T.J. is correct, of course, that my original suggestion would make
multiple copies of the functions. That's what I get for writing off
the top of my head. If I understand correctly, what joe t. really
want is something like:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
meta http-equiv=Content-Type content=text/html; charset=UTF-8
titleSpecialDate/title
script
var specialDateFactory = function () {
var calcIsEaster = function () {
// do something with _this_, which will be a Date object
this.isEaster = true; // replace with real code
}
var calcIsLaborDay = function () {
// do something with _this_, which will be a Date object
this.isLaborDay = false; // replace with real code
}
return function () {
var that = new Date();
that.calcIsEaster = calcIsEaster;
that.calcIsEaster();
that.calcIsLaborDay = calcIsLaborDay;
that.calcIsLaborDay();
return that;
}
} ();
/script
/head
body
script
var myDate = specialDateFactory();
document.write(pmyDate.isEaster: + myDate.isEaster + /p);
document.write(pmyDate.calcIsLaborDay: + myDate.calcIsLaborDay +
/p);
document.write(pmyDate instanceof Date: + (myDate instanceof
Date) + /p);
/script
/body
/html
The factory function specialDateFactory returns a Date instance which
has methods calcIsEaster and calcIsLaborDay, and properties isEaster
and isLaborDay. If you change the value of the returned object, you
can call calcEaster and calcIsLaborDay again to refresh .isEaster
and .isLaborDay.
What's more, the functions like calcIsEaster and calcIsLaborDay can
call each other securely -- no matter how objects returned from
specialDateFactory are abused, variables in the closure are
undisturbed. So you can securely add lookup tables and helper
functions hidden from the outside.
And this introduces only one closure, so it's fairly cheap.
JavaScript constructors are an anomalous, pseudo-classical things.
If you're not going to compare objects with instanceof, don't bother
with them. More often, factories are what you really want.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
On May 21, 11:11 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Joe,
T.J.'s factory suggestion...
FWIW, I think it was Doug's suggestion, I just updated it a bit.
function DateFactory(){
var fName, that = new Date();
for (fName in SpecialDateProps)
that[fName] = SpecialDateProps[fName](); // Note calling the
fName's function.
return that;
}
I'm not immediately seeing how that works. There are two problems I
see:
1. When you're calling the functions, they don't have any context to
work with. How do they know what date they're meant to be working on?
Which means creating setters and getters so that when the date is
modified, properties can be adjusted accordingly. However, that means
setters may be doing more work than they need to - why work out if a
date is easter or not if the code using it date doesn't care?
2. Date instances are mutable, but you're setting a flag on the date
just once at creation time. So even if the flag is correct at the
time the instance is created, it can be made incorrect by using any of
the mutator functions (setMonth, etc.).
Either the setter needs to update such propeties, or isEaster needs to
be a method, not a boolean. It all boils down to understanding the
requirements first, then designing the software to suit.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
On May 20, 12:16 am, RobG rg...@iinet.net.au wrote: On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote: This is a case when you really truly want just the facilities that Javascript provides (prototypes rather than classes), and using (pretend) classes makes it harder not easier. Yes, although some may argue that it is better to create a new object that has the required methods and leverages the methods of Date, rather than modifying a built-in object prototype, Fair comment. But you are still talking about using Javascript's prototype, rather than inventing classes. That was my point. (I wouldn't have made this remark before I read Crockford's Javascript: The Good Parts - that's opened my eyes to the strengths that JS has. ) Colin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
You can get more sophisticated - creating a prototype object for
special dates, with the functions defined on it, and using closures to
protect it, but I can't write that off the top of my head...
On May 20, 7:50 am, ColinFine colin.f...@pace.com wrote:
On May 20, 12:16 am, RobG rg...@iinet.net.au wrote:
On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote:
This is a case when you really truly want just the facilities that
Javascript provides (prototypes rather than classes), and using
(pretend) classes makes it harder not easier.
Yes, although some may argue that it is better to create a new object
that has the required methods and leverages the methods of Date,
rather than modifying a built-in object prototype,
Fair comment. But you are still talking about using Javascript's
prototype, rather than inventing classes. That was my point.
(I wouldn't have made this remark before I read Crockford's
Javascript: The Good Parts - that's opened my eyes to the strengths
that JS has. )
Colin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
T.J.,
i think my last post was at least somewhat in line with your
suggestion. i just hadn't fully read and absorbed yours yet.
i will try using that factory approach. If i'm reading it right, it
handles the two-line requirement of creating the native Date, then
calling the ApplySpecialProps method.
As always, thanks for the help!
-joe
On May 20, 12:23 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Heya,
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
The problem with that as written is that it creates separate isEaster
and isLaborDay functions for every single instance you create, each of
which eats memory:
var a = specialDateFactory();
var b = specialDateFactory();
alert(a.isEaster === b.isEaster); // false
You can avoid that:
var MoreDateFunctions = {
isEaster: function () {return ...},
isLaborDay: function () {return ...}};
function specialDateFactory() {
return Object.extend(new Date(), MoreDateFunctions);
// Or, without Prototype's Object.extend:
// var fname, that;
// that = new Date();
// for (fname in MoreDateFunctions) {
// that[fname] = MoreDateFunctions[fname];
// }
// return that;
}
...but I'm not seeing much benefit at that point. I suppose it means
you haven't modified the Date prototype.
(BTW: Anyone tempted to create an ExtendedDate object using a Date
object as its prototype, think again, for some reason the spec
specifically disallows it in Section 15.9.5, and Firefox [and probably
others] implements the limitation.)
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On May 20, 4:07 pm, P. Douglas Reeder reeder...@gmail.com wrote:
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
You can get more sophisticated - creating a prototype object for
special dates, with the functions defined on it, and using closures to
protect it, but I can't write that off the top of my head...
On May 20, 7:50 am, ColinFine colin.f...@pace.com wrote:
On May 20, 12:16 am, RobG rg...@iinet.net.au wrote:
On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote:
This is a case when you really truly want just the facilities that
Javascript provides (prototypes rather than classes), and using
(pretend) classes makes it harder not easier.
Yes, although some may argue that it is better to create a new object
that has the required methods and leverages the methods of Date,
rather than modifying a built-in object prototype,
Fair comment. But you are still talking about using Javascript's
prototype, rather than inventing classes. That was my point.
(I wouldn't have made this remark before I read Crockford's
Javascript: The Good Parts - that's opened my eyes to the strengths
that JS has. )
Colin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
Thanks to all for your feedback. i think though, that some of the
focus has remained on adding new *methods* to the Date object. That's
easy enough, as in my first sample. However, i'm trying to add
properties to the object that obtain a value when a new Date is
constructed.
var myDate = new Date();
alert(myDate.isEaster); // Alerts 'true' or 'false'
alert(myDate.isLaborDay); // Alerts 'true' or 'false'
etc.
i realize that these property values would still need to be obtained
from return values of functions. That's why my second sample includes
the _isEaster methods, but also has this.isEaster receiving the
return value of the _isEaster method.
Consider:
if (myDate.isEaster){alert('Happy Easter');
vs
if (myDate.isEaster()){alert('Happy Easter');
Any time i want to utilize, compare, etc. that the date is or is not
Easter, i can either have a quick-access boolean property, or a
lengthy calculation from a method.
Obviously these are simplified examples, but when applied to the
bigger concept of reserved dates, and that these reservations could
overlap (isEaster isMyBirthday, for instance), property testing
could reduce some decent calculation overhead.
However, if it can't be done, it can't be done. i suppose i can simply
add a second line after constructing a new Date:
Date.prototype.ApplySpecialDateProps = function(){
this.isEaster = (function(d){
// Calculate something from d
return ... })(this),
this.isLaborDay = (function(d){
// Calculate something from d
return ... })(this),
...
}
var myDate = new Date();
myDate.ApplySpecialDateProps();
i was just hoping to get the special properties to be part of the Date
object's construction.
-joe
On May 20, 12:23 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Heya,
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
The problem with that as written is that it creates separate isEaster
and isLaborDay functions for every single instance you create, each of
which eats memory:
var a = specialDateFactory();
var b = specialDateFactory();
alert(a.isEaster === b.isEaster); // false
You can avoid that:
var MoreDateFunctions = {
isEaster: function () {return ...},
isLaborDay: function () {return ...}};
function specialDateFactory() {
return Object.extend(new Date(), MoreDateFunctions);
// Or, without Prototype's Object.extend:
// var fname, that;
// that = new Date();
// for (fname in MoreDateFunctions) {
// that[fname] = MoreDateFunctions[fname];
// }
// return that;
}
...but I'm not seeing much benefit at that point. I suppose it means
you haven't modified the Date prototype.
(BTW: Anyone tempted to create an ExtendedDate object using a Date
object as its prototype, think again, for some reason the spec
specifically disallows it in Section 15.9.5, and Firefox [and probably
others] implements the limitation.)
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On May 20, 4:07 pm, P. Douglas Reeder reeder...@gmail.com wrote:
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
You can get more sophisticated - creating a prototype object for
special dates, with the functions defined on it, and using closures to
protect it, but I can't write that off the top of my head...
On May 20, 7:50 am, ColinFine colin.f...@pace.com wrote:
On May 20, 12:16 am, RobG rg...@iinet.net.au wrote:
On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote:
This is a case when you really truly want just the facilities that
Javascript provides (prototypes rather than classes), and using
(pretend) classes makes it harder not easier.
Yes, although some may argue that it is better to create a new object
that has the required methods and leverages the methods of Date,
rather than modifying a built-in object prototype,
Fair comment. But you are still talking about using Javascript's
prototype, rather than inventing classes. That was my point.
(I wouldn't have made this remark before I read Crockford's
Javascript: The Good Parts - that's opened my eyes to the strengths
that JS has. )
Colin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
[Proto-Scripty] Re: Adding properties to native objects
Heya,
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
The problem with that as written is that it creates separate isEaster
and isLaborDay functions for every single instance you create, each of
which eats memory:
var a = specialDateFactory();
var b = specialDateFactory();
alert(a.isEaster === b.isEaster); // false
You can avoid that:
var MoreDateFunctions = {
isEaster: function () {return ...},
isLaborDay: function () {return ...}
};
function specialDateFactory() {
return Object.extend(new Date(), MoreDateFunctions);
// Or, without Prototype's Object.extend:
// var fname, that;
// that = new Date();
// for (fname in MoreDateFunctions) {
// that[fname] = MoreDateFunctions[fname];
// }
// return that;
}
...but I'm not seeing much benefit at that point. I suppose it means
you haven't modified the Date prototype.
(BTW: Anyone tempted to create an ExtendedDate object using a Date
object as its prototype, think again, for some reason the spec
specifically disallows it in Section 15.9.5, and Firefox [and probably
others] implements the limitation.)
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On May 20, 4:07 pm, P. Douglas Reeder reeder...@gmail.com wrote:
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
You can get more sophisticated - creating a prototype object for
special dates, with the functions defined on it, and using closures to
protect it, but I can't write that off the top of my head...
On May 20, 7:50 am, ColinFine colin.f...@pace.com wrote:
On May 20, 12:16 am, RobG rg...@iinet.net.au wrote:
On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote:
This is a case when you really truly want just the facilities that
Javascript provides (prototypes rather than classes), and using
(pretend) classes makes it harder not easier.
Yes, although some may argue that it is better to create a new object
that has the required methods and leverages the methods of Date,
rather than modifying a built-in object prototype,
Fair comment. But you are still talking about using Javascript's
prototype, rather than inventing classes. That was my point.
(I wouldn't have made this remark before I read Crockford's
Javascript: The Good Parts - that's opened my eyes to the strengths
that JS has. )
Colin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
One last note barring any huge revelations:
T.J.'s factory suggestion was almost exactly right. His code as-is
adds the methods to my customized Date. However, since i want
properties of the same name that receive the return values of those
methods, i MUST use the non-Object#extend version, as such:
var SpecialDateProps = {
isEaster:function(){ return ... },
etc.
};
function DateFactory(){
var fName, that = new Date();
for (fName in SpecialDateProps)
that[fName] = SpecialDateProps[fName](); // Note calling the
fName's function.
return that;
}
Thanks again!
-joe t.
On May 20, 1:12 pm, joe t. thooke...@gmail.com wrote:
T.J.,
i think my last post was at least somewhat in line with your
suggestion. i just hadn't fully read and absorbed yours yet.
i will try using that factory approach. If i'm reading it right, it
handles the two-line requirement of creating the native Date, then
calling the ApplySpecialProps method.
As always, thanks for the help!
-joe
On May 20, 12:23 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Heya,
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
The problem with that as written is that it creates separate isEaster
and isLaborDay functions for every single instance you create, each of
which eats memory:
var a = specialDateFactory();
var b = specialDateFactory();
alert(a.isEaster === b.isEaster); // false
You can avoid that:
var MoreDateFunctions = {
isEaster: function () {return ...},
isLaborDay: function () {return ...}};
function specialDateFactory() {
return Object.extend(new Date(), MoreDateFunctions);
// Or, without Prototype's Object.extend:
// var fname, that;
// that = new Date();
// for (fname in MoreDateFunctions) {
// that[fname] = MoreDateFunctions[fname];
// }
// return that;
}
...but I'm not seeing much benefit at that point. I suppose it means
you haven't modified the Date prototype.
(BTW: Anyone tempted to create an ExtendedDate object using a Date
object as its prototype, think again, for some reason the spec
specifically disallows it in Section 15.9.5, and Firefox [and probably
others] implements the limitation.)
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On May 20, 4:07 pm, P. Douglas Reeder reeder...@gmail.com wrote:
You may want to use Crockford's factory pattern, rather than using any
sort of constructor:
function specialDateFactory() {
var that = new Date();
that.isEaster = function () {return ...},
that.isLaborDay = function () {return ...},
return that;
}
You can get more sophisticated - creating a prototype object for
special dates, with the functions defined on it, and using closures to
protect it, but I can't write that off the top of my head...
On May 20, 7:50 am, ColinFine colin.f...@pace.com wrote:
On May 20, 12:16 am, RobG rg...@iinet.net.au wrote:
On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote:
This is a case when you really truly want just the facilities that
Javascript provides (prototypes rather than classes), and using
(pretend) classes makes it harder not easier.
Yes, although some may argue that it is better to create a new object
that has the required methods and leverages the methods of Date,
rather than modifying a built-in object prototype,
Fair comment. But you are still talking about using Javascript's
prototype, rather than inventing classes. That was my point.
(I wouldn't have made this remark before I read Crockford's
Javascript: The Good Parts - that's opened my eyes to the strengths
that JS has. )
Colin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
This is a case when you really truly want just the facilities that
Javascript provides (prototypes rather than classes), and using
(pretend) classes makes it harder not easier.
Date,prototype.isEaster = function() { ... };
etc.
Colin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote:
This is a case when you really truly want just the facilities that
Javascript provides (prototypes rather than classes), and using
(pretend) classes makes it harder not easier.
Yes, although some may argue that it is better to create a new object
that has the required methods and leverages the methods of Date,
rather than modifying a built-in object prototype, something like:
function SpecialDate(d) {
this.date = new Date(d);
}
SpecialDate.prototype = {
getYear: function() {
return this.date.getFullYear();
},
isEaster: function() {
var easterStart = new Date('2009/04/10 00:00');
var easterEnd = new Date('2009/04/13 23:59:59')
return (this.date = easterStart this.date = easterEnd);
}
}
var d = new SpecialDate('2009/04/12');
alert(d.isEaster());
Of course, the above is only useful for easter 2009 and needs further
development, however it shows the general idea. The work of JR
Stockton might help:
URL: http://www.merlyn.demon.co.uk/js-dobj2.htm
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
On Tue, May 19, 2009 at 8:16 PM, RobG rg...@iinet.net.au wrote: On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote: This is a case when you really truly want just the facilities that Javascript provides (prototypes rather than classes), and using (pretend) classes makes it harder not easier. Yes, although some may argue that it is better to create a new object that has the required methods and leverages the methods of Date, rather than modifying a built-in object prototype[snip] I fully agree on that, but since OP is using prototype.js, who already extends a lot of built-in objects, it doesn't make a difference. Gabriel Gilini www.usosim.com.br gabr...@usosim.com.br --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
Hi,
Expanding on Gabriel's answer, mostly if you just fix your
Object.extend calls to point to the prototype rather than the
constructor, you should be fine. E.g.:
Object.extend(Date.prototype, {
...
});
Look at the Prototype source and how it extends String, for instance,
for examples.
HTH,
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On May 18, 5:57 pm, joe t. thooke...@gmail.com wrote:
i haven't had much luck finding what i'm looking for, so maybe i'm not
looking for it correctly.
i want to add several properties (booleans indicating special dates)
to the native Date object that are assigned when the date is
instantiated. However, i'm not sure how i can do that.
i know i can extend Date with methods that return a boolean:
Object.extend(Date,{
isEaster:function(){return ...},
isLaborDay:function(){return ...},
etc.
});
but as far as i know, they have to be called after the Date is
created. i'm trying to simulate native properties, eg:
Date = Class.create(Date, {
initialize:function(){
$super(arguments[0], ...);
this.isEaster = this._isEaster();
this.isLaborDay = this.isEaster ? false : this._isLaborDay();
// etc...
},
_isEaster:function(){ return ... },
_isLaborDay:function(){ return ... }
});
i'm AWARE the above Class call doesn't work. But something like that
is what i'm trying to achieve. How can i modify the native object's
constructor to do its normal call, and also assign these properties?
Any help?
-joe t.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
