[eastgate]

I don't think we should refight the question of encapsulation here. Some people think encapsulation-by-convention is adequate, others don't.

I'm also positing Crockford-style modules.(Since it's pretty clear from the context that I'm following Crockford, you might assume that I know about the Javascript/LISP connection.)

The question remains: is repeated use of "this"

     this.Mill();
     this.Drill();
     this.Fill();

simply semantic vinegar, or does it suggest that the object is not doing its job -- or that we need a new object?

[grayrest]

The problem is that you're applying C++ sensibilities to a prototype OO language. `this` doesn't refer to the current class, but to the current object. There are no classes and no methods. Functions don't even really belong to the object they're written in. You can easily rebind (using call/apply) a function to a different object so that it operates as a 'method' of that object. If you have a few minutes, dig up 'Self the video', skip the intro and watch how objects/methods are pulled apart and stuck together. That's the conceptual basis for the object system and it's pretty common for libraries to take advantage of changing `this` to a different object (e.g. `this` is the target element in a jQuery event handler). Opinions are mixed on whether this is ultimately a good idea, but it's part of the language.

Having come from Python to Javascript, I consider this to be explicit and a feature rather than a code smell. I dislike when a language's include constructs dump everything into the local namespace and the `this` is implicit because it means that I can't look at a piece of code in isolation without IDE support and figure out where a particular reference is resolving.

If it really bothers you, coffeescript uses @ in place of this:

    Product::make = () ->
        @mill()
        @drill()
        @fill()