Hi,
> What's most interesting to me is that my 'way' of programming has been
> to do something like this:
[snip]
> Where I make "private" methods at the end of my class prefaced with an
> _ in the name... Looking at how you work, it appears you would do
> something like this instead:
>
> ************************************************
> // stuff...
> foo: function() {
> doSomething();
> doSomethingWithThis.bind(this);
>
> function doSomething() {
> //something without this
> }
>
> function doSomethingWithThis() {
> //something with this..
> }
>
> }
That's not quite what my structure would be, no, but I can understand
how you got there from the tweaks to your code I posted. I was in
"minimal update" mode and so mostly left your code alone. Two notes on
that code quoted above: 1. I very, very rarely use anonymous functions
assigned to properties like that (`foo: function() { ...`). Almost
never, in fact. 2. I'll only define functions within other functions
(at least, in the way used in that example) if there's a really good
reason for them all to be in that execution context like that (e.g., a
lot of shared state in vars AND a good reason for it). Mostly I prefer
to have private utility methods declared at what I tend to think of as
"class" level. This is because when they're in the function, they get
redefined every time the function is called. Mostly that's harmless,
but...
This is my basic structure, which is just a specific way of writing
the module pattern and some naming conventions:
var Thingy = Class.create((function() {
var pubs = {};
pubs.initialize = Thingy_initialize;
function Thingy_initialize() {
}
pubs.foo = Thingy_foo;
function Thingy_foo() {
}
function somePrivateUsedByFoo() {
}
pubs.bar = Thingy_bar;
function Thingy_bar() {
somePrivateUsedByBar(); // If `this` doesn't matter
someOtherPrivateUsedByBar.call(this); // If it does
this.foo(); // Call publics by their public name
}
function somePrivateUsedByBar() {
}
function someOtherPrivateUsedByBar() {
}
function someGeneralPurposePrivateFunction() {
}
function someOtherGeneralPurposePrivateFunction() {
}
return pubs;
})());
(Except I don't use Class.create directly, I have a wrapper, but it
doesn't change much of the above.) So I tend to keep functionality
together -- #foo and the things it uses tend to be near one another,
#bar and the things it uses tend to be near one another. Miscellaneous
subroutines for the class tend to collect at the bottom; miscellaneous
class-wide data tends to collect at the top (that's a by-product of my
approach to `var`[1]; there's no particularly good reason they
couldn't be at the bottom along with the subroutines, though, nor is
ther a reason the subs couldn't be at the top with them).
Key points for me about that structure:
1. Scoping function for "class"-wide scope.
2. A `pubs` object that will be the return value of the scoping
function.
3. Incorporating the name of the class into the names of the public
functions, despite the repetitiveness (configurable editors are
wonderful).
4. Not doing so with private functions (overkill).
5. Binding public functions to appropriate (shorter) names on the
`pubs` object.
6. Doing that binding right there where the function is declared (it's
too easy to forget otherwise).
I've gone through several iterations of the structure, balancing
verbosity with maintainability, but that's where I am right now. :-)
> When you say that about state flags, do
> you mean stuff like:
> if (!admin_table.periodical_executer.request_in_progress)
>
Yes. IIRC, you have two of three of these working together.
> Why exactly is 'chained execution' preferred?
Well, *I* prefer it much of the time, which is very different from
saying "it is preferred." :-) (I also prefer putting the opening curly
brace on its own line, but I recognize that there are maybe four
people in the world who agree with me on that and so I don't do it
when posting for others to read.) I prefer chained execution mostly
because it's harder to forget to stop it. I started using it the third
time I forgot to make a periodic form modification function stop
running when taking the form off the page and only realized it when it
seemed like the app was getting really slow (because I had ended up
with a dozen of them running). Specifically in your case, I would use
one because of the race condition -- your periodic executer and your
ajax call are in a race, and you had to use that state flag to prevent
side-effects, and in a way that meant if the ajax call finished just
*one* millisecond after the executer tried to run and was blocked,
that whole cycle was skipped, rather than being just delayed.
Now, for situations where you really need to define the interval from
start-of-execution to start-of-execution, you don't want chained
execution, which is timed from end-of-execution to start-of-next-
execution (although you can achieve the former by adjusting the time
you set for the next call, I suppose; that starts getting complicated
though).
> > Oh, and I'm a named function guy
[snip]
> Very interesting also... Btw, I caught a typo
Thanks! Fixed.
> Reading that post made me realize how I really don't utilize my
> debugging tools...
[snip]
> My method of 'debugging'
> has been to throw "console.log('here');" at random points in my code
> to see if it's reaching that point...
[snip]
> Do you have any advice on how I can learn this sort of thing?
"By doing" is all I have, sorry. No one ever taught me how to read a
call stack either. :-) But specifically: Firebug has a pretty darned
good debugger in it, there's no reason for "console.log('here')"! When
debugging, just open the Firebug window/pane, choose the Script tab,
select the relevant file, and there's your code. Click in the gutter
to the left of a line of code and it inserts a breakpoint. When that
line of code is about to be run, Firebug will pop up and everything
will stop. You can then walk through your code, executing it line by
line to see what's going on and what the state of your variables is at
any given moment. It remembers your breakpoints even when you reload.
It's a quite rich debugging environment. So are Chrome's "Developer
Tools" (Ctrl+Shift+I, or choose it from the page menu), although
Chrome's DevTools are still catching up to Firebug. Have a read
through this page[2] on the Firebug web site.
[1] http://blog.niftysnippets.org/2008/03/poor-misunderstood-var.html
[2] http://getfirebug.com/javascript
HTH,
-- T.J.
On Apr 11, 8:55 am, patrick <[email protected]> wrote:
> Thanks T.J.,
>
> Very good suggestions, and it's always interesting to see how other
> people (more experienced too) would handle certain things.
>
> What's most interesting to me is that my 'way' of programming has been
> to do something like this:
>
> ****************************************
> var Foo = (function() {
> var Foo = Class.create({
> foo: function() {
> _doSomething(this); // if I am not going to use the
> instance
> this.doSomething() // if I am going to use the instance
> },
>
> doSomething: function() {
> // something with this
> }
>
> });
>
> function _doSomething() {
> // something without this
> }
>
> return Foo;
>
> })();
>
> *******************************************
>
> Where I make "private" methods at the end of my class prefaced with an
> _ in the name... Looking at how you work, it appears you would do
> something like this instead:
>
> ************************************************
> // stuff...
> foo: function() {
> doSomething();
> doSomethingWithThis.bind(this);
>
> function doSomething() {
> //something without this
> }
>
> function doSomethingWithThis() {
> //something with this..
> }
>
> }
> // stuff...
>
> ......
>
> Which is very different for me... On one hand, I wouldn't need to go
> scrolling down to the bottom of my file to look at what those private
> methods are doing-- they'd be right there where ever they're being
> referenced... On the other hand, it would mean that my class methods
> would end up looking a lot 'bigger'.
>
> > For this, I probably wouldn't use a periodical executer, either,
> > because of all the state flags required. I'd probably go with chained
> > execution:
>
> I am curious about this... When you say that about state flags, do
> you mean stuff like:
> if (!admin_table.periodical_executer.request_in_progress)
>
> ?
>
> Why exactly is 'chained execution' preferred?
>
> > Oh, and I'm a named function guy (I notice you're using an anonymous
> > function for your `autoUpdate` property); here's
> > why:http://blog.niftysnippets.org/2010/03/anonymouses-anonymous.html
>
> Very interesting also... Btw, I caught a typo: (that's should be
> that)
> "Well, okay, that's does work, but it still has some issues:"
>
> Reading that post made me realize how I really don't utilize my
> debugging tools... I don't think I understand them very well. I use
> firebug to test things in the console, and to monitor the html output
> that changes dynamically through javascript. My method of 'debugging'
> has been to throw "console.log('here');" at random points in my code
> to see if it's reaching that point...
>
> Quite often when there is an error, I am frustrated because I get
> messages like "A is null", and I usually say outloud "gee thanks.."
> wondering what the hell "A" is.. or the other common error I get is
> whatever class I am working on is undefined, and it's usually a
> missing semicolon somewhere. Reading your blog made me say: wow..
> I've never been trained to know how to follow a stack trace-- so
> named / unnamed functions has never been an issue to me because that
> sort of debuggin is just something I have not really understood how to
> do. Do you have any advice on how I can learn this sort of thing?
>
> -patrick
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
