Module/JSON: unexpected behaviour

[GoogleCodeExporter]

Take this:
    base2.JSON.String.toJSONString("I said no!") == "I said no!"

but (unexpected)
    var f=base2.JSON.String.toJSONString;
    f("I said no!") == "I%20said%20no%21"

and (explanation)
    var f=base2.JSON.String.toJSONString;
    f.call(base2.JSON.String, "I said no!") == "I said no!"
    this.escape("I said no") == "I%20said%20no%21"
   escape("I said no") == "I%20said%20no%21"

It took me some time to figure this out, because I though a found a bug. The 
inquiry: it's a bit invisible 
with JSON whether you're dealing with a function or a method. Should we (and 
can we) do something 
about this?

A question: with modules, you can in interface methods refer with "this" to 
static members. But you 
can't in Base classes. Is this by design? The difference confused me.

BTW: can you create a "Type-Inquiry" label (if you think it's a good idea)? 
It's just a bit friendlier for all 
of us (and keeps us from the emotional excitement: THIS IS NOT A DEFECT).

Original issue reported on code.google.com by doek...@gmail.com on 27 Jul 2007 at 8:14

[GoogleCodeExporter]

> var f=base2.JSON.String.toJSONString;
> f.call(base2.JSON.String, "I said no!") == "I said no!"
> this.escape("I said no") == "I%20said%20no%21"

This is a coincidence really. Normally when you detach a JavaScript method it 
doesn't
work at all. This works in a strange way because JSON.String and the global 
object
both define an escape() method.

On a general note, and to answer your second question, Modules are static 
objects
that just happen to be classes. All methods are static! That is why "this" 
works for
static members. The prototype is built by delegating object methods to their
equivalent static method. That way, modules can act as mixins too.

See this for an example:

http://base2.googlecode.com/svn/trunk/src/base2/Module.txt

> BTW: can you create a "Type-Inquiry"

Will do. I'll also create Type-Discussion.

Original comment by dean.edw...@gmail.com on 27 Jul 2007 at 9:19

[GoogleCodeExporter]

I realized the coincidence. 

I know how I can use Modules. I just haven't looked at the inner workings. Or 
better: I opened the file, and 3 
seconds later closed it again. I might open the file again, some other time ;-)

But, if you do:
  var addClass=base2.DOM.HTMLElement.addClass;
  addClass(document.body, "bold");

you get this error:
  Value undefined (result of expression this.hasClass) is not object.

I just think some people are going to make this mistake, and will look in the 
wrong places to solve this. Eventually, 
they will see their mistake (and realize mixins are cool), or for the worse: 
work around the mistake (and never 
realize mixins are subzero). Either way: there's some cognitive disonance.

With other words: can we "fix" this non-technical usability error easy?

Original comment by doek...@gmail.com on 27 Jul 2007 at 9:51

• Changed state: Started
• Added labels: Type-Discuss
• Removed labels: Type-Inquiry

[GoogleCodeExporter]

Are you saying that people will expect Module methods to be detachable like 
this?

Original comment by dean.edw...@gmail.com on 27 Jul 2007 at 10:26

[GoogleCodeExporter]

In a way, I guess. Like I now know what I can do with Module doesn't mean I 
fathom the complete concept. When I 
encountered the issue, I didn't even realize base2.JSON.String *was* a Module.

And I also can imagine, people will not grasp the concept of Module enough, to 
withhold them  making this mistake 
(made up innermind conversation of some developer: "hey, modules, cool. You can 
apply them to classes, and use 'm 
standalone. That's a lot of syntax. Let's create a shortcut variable"...).

But for my sake they don't need to be used detached. Can't we add some checks, 
so an meaningful exception is thrown 
when a module-method is used detached?

Original comment by doek...@gmail.com on 27 Jul 2007 at 10:38

[GoogleCodeExporter]

You know that all of base2.DOM is written as Modules? That's why you can do 
this:

HTMLElement.addClass(element, "cool");   // as module

or:

HTMLElement(element);                    // as mixin
element.addClass("cooler");

you can also do this of course:

HTMLElement(element).addClass("cooler");

I'm not sure what to do about detaching Module methods. It would be a nice 
feature. I
need to think about it for a bit...

Original comment by dean.edw...@gmail.com on 27 Jul 2007 at 10:57

[GoogleCodeExporter]

If you can address the issue with not too much trouble, it would be great.

The bigger issue is I think addressing layer leakage. Base2 adds new concepts 
on top of javascript. But once and a 
while, some javascript things leak though. We need to keep the leakage as low 
as possible, and when inevitable, 
provide a towel (a meaningful exception, documentation).

Original comment by doek...@gmail.com on 27 Jul 2007 at 11:10

[GoogleCodeExporter]

I'm closing this issue (the original bug was fixed long ago).

As to detachable module methods, raise another issue for this if you think it is
important.

Original comment by dean.edw...@gmail.com on 10 Aug 2007 at 4:21

• Changed state: Fixed