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" - 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
-~----------~----~----~----~------~----~------~--~---
