Making Joose more robust

[Malte Ubl]

Hey,

Joose depends on playing nice with other JS libraries and user code
that does weird stuff.

I have commited an experimental test library called Test.RealWorld to
test this. It still needs to get support from Test.TAPBrowser. I think
the best thing would be to create a new iframe for each method in
Test.RealWorld and then execute it in the iframe before executing all
tests.

Bye the way: While I do not really know this for sure, it is almost
certain that tests will fail after loading Prototype. We might have to
live with that.

What do you think?

bye
Malte

[Malte Ubl]

OK,

I just implemented this:
You can now call methods out ouf Test.RealWorld using:
test.html#real_world=extendObject

Preliminary results: we suck
- Extending Object breaks us
- Extending Array seems to break at least Moose.Storage.jsonpickle
- We do not run with Prototype
- We do not run with Mootools

The first two will have to be fixed. I am not sure about the latter.
We conflict on several important global variables (Prototype, Class)
and fixing this will be hard (although, not impossible)

Should compatibility with Prototype be a goal or is prototype too legacy?

Malte

[Malte Ubl]

We now run with extended Object and Array prototype:

From now on, please use
Joose.O.eachSafe instead of Joose.O.each unless neccessary.

Bye
Malte

[Malte Ubl]

Hmm, f*ck it, I fixed Joose under Prototype.

On Sun, Oct 26, 2008 at 3:18 PM, Malte Ubl <malt...@gmail.com> wrote:

[Jeremy Wall]

Prototype.js is a javascript library that should never have been invented. For precisely this reason. Most other libraries play fairly nice with namespaces.

The easy declarative syntax that Joose shares with Moose are what attracted me to it. Perhaps we should consider our audience a little before jumping into the prototype library train? I'm not sure we want to structure Joose around another libraries bad design decisions.

Maybe the right thing to do is come up with some way of telling the user when a loaded library is doing "bad" things? Sort of autodetecting NameSpace pollution?

These are just some random thoughts off the top of my head so I'll try to formulate something more coherent after I've gotten some sleep and had a look at your test suite.

2008/10/26 Malte Ubl <malt...@gmail.com>

[Malte Ubl]

Hey,

the reason I put in the changes to please Prototype weren't really to
support Prototype (which I consider legacy) but rather because it will
eventually help us with oher problems (or people doing similar things
as Prototype did)

We had to to fix the problems with extended Object.prototype.
Prototype doesn't even do this, but people will.
Joose currently depends on the some global functions which have names,
that can easily conflict with other libraries or user code. This is
now no longer the case.

So, I think it is a good thing these changes went in. A lot of people
will get less bad surprises while working with Joose.

Bye
Malte

PS: I put some evil hacks into Test.TAPBrowser in my last commit. I'll
take care of removing these :)

[Mike Walker]

Hi Malte,

FYI, I thought this might be related to your recent Prototype fun.

I just checked in two coercions for Bool ("true" and "false"), and in my
fresh checkout I noticed that test 14_modules.t.js fails now:

not ok 25 - code threw [ ] expected: [here is already something else]

The line is :

self.throws_ok(function () {com.test.module.meta.alias(thistop)}, "here
is already something else", "Importing fails if there is already
something else")

Cheers,
Mike

[Malte Ubl]

The failing test in 14_modules is unrelated to the changes in that
were done to support Prototype. It was like that when I startet
coding tomorrow morning, but I havenÄt been able to track it down.

Malte