Thursday 22 December 2011

Ill-Considered Smartphone Griping

My current phone, a Samsung Galaxy S, is the first smartphone and by far the most expensive phone that I've owned. And sometimes it hacks me off far more than any past phone. Let me start by saying that smartphones are amazing devices. They're so far beyond phones it's not funny. And that's sort of the problem; there's so much potential there, and the phone forces your expectations high by being so neat in so many way.

I'm likely to invest in a backup phone soon which is just a phone purely so I have a more rugged, less expensive phone with a less fleeting battery life. I just can't get comfortable heading out on the bike for a day with my SGS tucked in the back of my jersey. Aside from anything, if I didn't remember to fully charge it before setting out then who knows if it'll still be working when I need it late on after disaster has struck. But I think that's fair enough, and not really a criticism of the SGS - or smartphones in general. Complaining that a smartphone doesn't work well as a long battery life, cheap, bombproof emergency backup phone is like complaining that bread makes a lousy sandwich filling; simultaneously right and dumb.

Some of what annoys me about the SGS is probably device-specific. Some of it is probably OS-specific. And some of it isn't the phones fault at all. But I still blame it, because it's the point at which the annoyance enters my life. So where to start...?

I suppose at the beginning. The SGS, as delivered, was shit. When I first got the SGS, it rapidly became apparent that various bits of it just didn't work. Samsung had cunningly designed a device whose GPS performance was so flaky as to be useless. Use it to navigate and you'd find your apparent location hopping around between neighbouring streets. Recording routes showed similar problems. An entire feature of the phone was working so badly, it would have been a better experience if it hadn't been implemented at all. Several months later - somewhere between six months and a year - and the GPS was finally fixed enough to use. Another massive problem with the phone was the file system: In their wisdom, Samsung decided to use a half-baked in-house mess called RFS (essentially FAT with an attempt at journalling tacked on). It's utter shit, and very rapidly access times plummet to the point that the phone lags whenever accessing storage. The community cooked up various lagfixes fairly quickly, but the experience out of the box was significantly worse than one would hope for. On top of all that the official support software for the phone, the route used for official updates, was so bug-ridden that it took me hours (including hacking the registry) to get it to work at all. And, of course, I had to boot a Windows VM to use it anyway since there's no support for linux hosts. Again, the community stepped in and have provided a variety of functional alternatives.

There were other issues too, but those were the headlines. And here's the thing.

I cannot - absolutely cannot - understand how a flagship device was released in such a state, or how it was left for so long without being officially fixed. I can only assume that no one in Samsung ever bothered to test any of this stuff before release. It's inexcusable, in my opinion, for such fundamental and blindingly obvious problems to be present especially in an ostensibly high-end device. I have NO desire to go through a similar process of cobbling my phone into functionality over a period of months again. I don't mind hacking it to tweak it, but in my opinion the above isn't tweaking. It's getting the damn thing working in the first place.

Moving on. There are things about the phone that even now hack me off. The one that annoys me most regularly, oddly, isn't strictly the phones fault at all but the BBCs. When listening to catch-up radio on my phone.... LET ME TURN THE FRICKING SCREEN OFF. The Beeb, in their wisdom, implemented (and by "implemented" I mean "hacked together and pretended they'd thought it through") iplayer for Android in flash. Which (a) means my wifes phone can't use it *at all* and (b) means it's shit. I mean, it works, but it's hideously inefficient and also keeps the screen turned on whilever it's running. Even if you're just listening to the radio. Power drain much? It pisses me off *so* much that Android is stuck with this shit when Apple devices aren't. I know the Apple ecosystem more established, but it's the BBC for fucks sake. They should be providing the same quality of service to all the major smartphone platforms. Anyway. More annoyances: When the battery runs low, the phone turns the screen on to tell you. And pops up a popup. Which won't dismiss until you press the appropriate button. And keeps the screen on until you do. When the battery is low. WELL PLAYED SIR. Also, even without the shonky file system, for no reason I can figure out the device briefly becomes laggy and unresponsive. Then recovers. Given I've owned less powerful PCs (fairly recently) than this device, I expect more than groaning as it tries to render a webpage because it's doing whatever housekeeping in the background.

And moving towards a more general point... I think largely what annoys me with the SGS, aside from the specifics, is any time I notice it pretending to be a phone not a computer. I mean, honestly, it's a pocket computer. It should act like one. And this is where I think lots - if not all - smartphones are going wrong (for the likes of me). Whenever I want to do something to the phone but I can't because I'm not allowed... that hacks me off. I'm used to computers that I *own* (like I own my phone!). That I can do anything to because they're fricking MINE. Now, yes, you can root an android phone to get this fundamental right of ownership back. But why should I have to? It's MY DEVICE.

Updating the SGS seems far more difficult than it should be. Maybe apt has spoiled me, but what I expect from my device is, basically, that the OS and all the software on it updates with no faff. Every Android update has been a hassle, with some of them randomly stopping various applications from working (and you'll only find out if you try to run them). And there's always eother the threat or promise of data loss. Unacceptable! Sort it the fuck out. ESPECIALLY if you're going to lock down the system for the average user so it's hard/impossible to fix stuff if it does go wrong. In fact, why do I have to stick with Android? Why can't I pay for the OS of my choice? It's just a little computer, after all.

One of the big things I was interested in doing before getting an SGS was writing stuff for it. I figured once I've actually got a device I can have a think about what I want to do with it. Yet since getting the SGS I've written *nothing* for it. There are a few reasons for this, one good, one bad, one indifferent. The good reason is that there's an awful lot of stuff already out there. I didn't need to write many of the apps I wanted. That's nice. The indifferent reason is that I *hate* writing the same thing twice. And almost everything I've wanted to do that I CAN do (see below) has been better served by just writing a web app. Then I can use it from anywhere, on any phone. The bad reason really annoys me, and although I knew this when I was getting the SGS it's only become more annoying as I've used it. And this is the big one. Fix this, and I'll buy your phone:

GIVE ME USB HOST SUPPORT, AND LET ME WRITE STUFF THAT USES IT.

They're COMPUTERS. Think of what we could do if we could use them to control USB devices! IT WOULD BE AWESOME. There are *so many things* we could do. And I keep thinking of them, and having to dismiss them because mobile phone manufacturers are knobs.

I'm fairly sure there was other stuff I wanted to grouse about, but I thought a quick stream of consciousness rant that actually got written was better than a well considered, complete but nonexistent essay.

Tuesday 26 July 2011

Why is ASP.net on mono like a new pet that hasn't been house trained?

...because it leaks all over the place.

We've been working for a while now on an MVC (initially MVC2, now MVC3) application running on mono 2.10.2 with FluentNHibernate 1.2 sitting on NHibernate 3.1, built as a web app but also available via a kiosked browser on the server. This effectively means we've got a web browser pointed at the server 24/7. In addition, it's a fairly heavily AJAX-ed application, pinging for data every second or so, which means we've got a browser sending requests to the application every second, 24/7. Still, not exactly heavy usage.

We've had a very, very hard time getting this working stably, and all of our troubles seem to be coming from the mono stack (possibly nhibernate as well, but even with that problem, it looks more likely that mono is the root cause). If you're putting together a web application using mono, you should probably look out for the following:


Memory leaks when running with sessions enabled

This seems to be something to do with CacheItems being created at a phenomenal rate without (apparently) ever being garbage collected. Even if you see no reason whatsoever why your application would be generating CacheItems, something under the hood will be there merrily churning them out. This will, eventually, bring your system to its knees before the mono process is killed. Switching garbage collectors to sgen (newer, better, see below...) doesn't help. This is almost certainly why mono web applications mysteriously stop working under heavy load according to the mono project.

Workarounds:

 You can, as suggested in the above link, restart your mono process every so often to release the memory. Not an ideal solution, obviously. Alternatively, if you don't need sessions you can run sessionless, which seems to stop this leak from happening (so it seems the CacheItems are being generated by something in the session code...). Or you could figure out what the fricking bug is and fix it.


An apparent race hazard when starting up a web app

If you choose to accept that you'll need to restart mono every so often, the next thing to watch out for is an intermittent exception when starting up. This occasionally manifests as an object not set to an instance of an object exception, but most commonly will appear as duplicate key exception thrown by the RoleManager - even when you aren't using roles for anything. To be honest, this being a race hazard is a total guess, I have no idea what the problem is, but something which is so intermittent just smacks of a race hazard. Since we didn't need sessions enabled, we simply switched to sessionless mode and stopped pursuing this one. Interestingly, since addressing all of the other problems listed in this post we've not seen any of these problems. So perhaps again something to do with the session code in mono...?

Workarounds:

 No idea. This seems to have just gone away as we've worked around all the rest of the weirdnesses. Best of luck to you if you're trying to solve this one. Sorry I can't help more.

Running the MVC sessionless is broken in mono

You should be able to run sessionlessly simply by adding the tag
< sessionstate mode="Off" > 
inside the system.web node in your web.config file. Providing you're not actually using TempData for anything, this should be fine. However, you'll get the following exception:

System.ArgumentNullException: Argument cannot be null.
Parameter name: httpSessionState
  at System.Web.HttpSessionStateWrapper..ctor (System.Web.SessionState.HttpSessionState httpSessionState) [0x00000] in <filename unknown>:0 
  at System.Web.HttpContextWrapper.get_Session () [0x00000] in <filename unknown>:0 
  at System.Web.Mvc.SessionStateTempDataProvider.LoadTempData (System.Web.Mvc.ControllerContext controllerContext) [0x00000] in <filename unknown>:0 
...

Workarounds:

According to the mighty Stack Overflow this has been fixed in .net. Alas not in mono. We worked around this by creating a dummy temp data provider
public class DummyTempDataProvider : ITempDataProvider
  {
   IDictionary ITempDataProvider.LoadTempData (ControllerContext controllerContext)
   {
    return null;
   }
   
   
   void ITempDataProvider.SaveTempData (ControllerContext controllerContext, IDictionary values)
   {
   }
  }

And then making sure all controllers overrode the CreateTempDataProvider function (since all our controllers inherit from a common base, we just stuck it in there).
protected override ITempDataProvider CreateTempDataProvider ()
  {
   //return base.CreateTempDataProvider();
   return new DummyTempDataProvider();
  }


Using the nHibernate WebSessionContext leaks memory

Our application uses nHibernate for persistence. Unfortunately, for some reason we've not been able to identify, if you use the WebSessionContext (which is what you should be using for a web application), you'll find that you are, once again, leaking memory. 

Workarounds:

 
We found that the ThreadStaticSessionContext has no such trouble and - on a hunch - tested out a hybrid session context we had lying around from an earlier project. This works fine, no leaks. The only real difference between this and the WebSessionContext seems to be that our HybridSessionContext uses the Items hashtable in the HttpContext directly to store the session whereas the WebSessionContext creates a new hashtable inside the items hashtable which uses the ISessionFactory as the key to the Session. Why this should cause a leak is a mystery; it may have nothing to do with the leak. But it's the only obvious difference.
internal class HybridSessionContext : CurrentSessionContext
 {
  [ThreadStatic]
  private static ISession threadSession = null;
  private const string webSession   = "YourNamespace.YourProject.WebContext";
  
  
  public HybridSessionContext(ISessionFactoryImplementor factory)
  {
  }
  
  
  protected override ISession Session
  {
   get 
   { 
    return (HttpContext.Current != null) ? HttpContext.Current.Items[webSession] as ISession : threadSession;  
   }
   
   set 
   { 
    if (HttpContext.Current != null)  HttpContext.Current.Items[webSession]  = value;
    else         threadSession        = value; 
   }
  }
 }


The boehm garbage collector causes further leaks

After all that, you may still be seeing leaks. We've found that the boehm garbage collector that mono uses by default is rather easily confused, especially, for some reason, when it comes to web applications. 

Workarounds:

Try switching to mono-sgen, the generational garbage collector (see the link above). We found this moved us from a still inexplicably-leaking application to one behaving normally... while testing on xsp. Because...



mod_mono causes even more leaks

After all of the above were resolved, and everything looked peachy testing locally through XSP, we pushed the system onto a target machine and ran through mod_mono instead.... and got yet more memory leaks.

Workarounds:

Run through xsp and use mod_proxy to serve it via apache. And you'll get back to not having leaks.

To summarise

Currently, I'd say that ASP.net on mono is a bit of a mess. You can work round the problems to some extent, but we've spent a ridiculous amount of time dealing with them. Unfortunately the mono mailing list on this subject seems to have gone very quiet (Dan in the list is the other part of the "we" that I refer to in this post), and we're sufficiently out of time that we simply cannot continue to bughunt for the underlying causes of these issues without at least some support from folks who know their way around the guts of mono better than we do.

Monday 13 June 2011

svn switch --relocate for a git-svn repo

Today, to my great annoyance, I discovered that if you're using git locally hooked up to a remote subversion server and you find yourself in a position where, if using svn only, you'd want to do svn switch --relocate ( for example, if the server has its address changed), git-svn presents you with a world of pain. Since the svn url gets baked into all the commit logs, and these are used to keep your git repo synced with the svn server, you can't just edit the .git/config file and change the url as you'd do for a normal git remote.

I'm not going to claim any credit for figuring out what the hell was going on; after a brief period of free-form jazz swearing at the machine with twenty-odd suddenly disconnected git repositories, I found a handy post explaining how to resolve this bloody annoying state of affairs.

Since I had a lot of repos to switch, I thought it best to write a little bash script to sort it all out for me. Here it is so you, too, can ease the pain of the unexpected subversion repository renaming with less hassle. Or, alternatively, utterly hose your repo. Seriously, this rewrites your commit logs and could do all kinds of the nasty. At least back up your local repository first before using it. And even then, you use it at your own risk, etc, etc:


#!/bin/bash
# git-svn-switch
# by Justen Hyde based on this blog post:
#
# http://translate.org.za/blogs/wynand/en/content/changing-your-svn-repository-address-git-svn-setup
#
# Use at your own risk. For the love of cthulhu, back
# your repo up before letting this loose on it.

if [ $# -ne 1 ]
then
  echo "Usage: `basename $0` {new subversion url}"
  exit -1
fi

if [[ $1 = "--help" || $1 = "-h" ]]
then
  echo
  echo "Usage: `basename $0` {new subversion url}"
  echo 
  echo " Changes the url of the subversion repository a git-svn repo is connected to." 
  echo " Analogous to svn switch. Potentially a weapon of mass destruction. Use with care."
  echo " Run this from within your git repo. You only need one argument: the new url of the svn repo."
  echo " git-svn-switch will attempt to verify that the url is at least a svn repo before starting the switch"
  echo " but don't depend on it to stop you from doing summat daft."
  echo
  exit 1
fi

# get the current subversion url
SRC=`git svn info --url`
if [ -n "$SRC" ]
then 
  FROM=`echo $SRC | sed "s|/trunk||"`
  REPO=`svn info $1`
  echo "Checking $REPO is actually a subversion repository..."
  if [ -n "$REPO" ]
  then 
    echo "The new URL looks valid."
    echo "Rewriting the git history with the new url..."
    SED_FILTER="sed 's;git-svn-id: "$FROM";git-svn-id: "$1";g'"
    git gc
    git filter-branch --msg-filter "$SED_FILTER" $(cat .git/packed-refs | awk '// {print $2}' | grep -v 'pack-refs')
#Couple of pointless checkouts - on some repos the log changes seem to need flushing by an operation like this
    git checkout trunk
    git checkout master
    echo "Rebuild git-svn internals and updating the repo"
    rm -rf .git/svn 
    sed -i~ 's|'$FROM'|'$1'|g' .git/config
    git svn rebase
  else
    echo "Error: $1 Does not appear to be a subversion repository."
  fi
else
  echo "Error: This doesn't appear to be a git working directory, or it's a git repo that hasn't been created using a git-svn bridge"
fi
EDIT: I've added a couple of checkouts to the script which don't serve any obvious purpose, just before rebuilding the internals. This is because I've found on some repos that for some reason git doesn't seem to notice the logs have been rewritten (git log shows you logs with the old address, but attempt to re-run the rewrite and git will behave as if the logs have been rewritten). Subversion seems to get the old version of the logs in this case, and so any operations trying to use the subversion address in the logs fail. Doing these checkouts seems to flush the logs properly and allow git-svn to behave as expected. Weird. Unfortunately, this does mean you have to have a reasonably standard repository structure (i.e., one that actually has a trunk that can be checked out) or the script will fail.

Wednesday 27 April 2011

Templates, inheritance and nested classes

I've recently had a world of fun and confusion with a strange combination of templating, inheritance and nested class in c++. The error messages along the way were rather weird, so in a bid to save time in future, here's the story:

Let's begin with a pretty standard templated class. It does useful things to some data which it keeps a hold of during its lifetime.
template <class T> class Foo
{
  public:
    Foo()  { /*...*/ }
    ~Foo() { /*...*/ }
    void SetStuff(T *data) { /*...*/ }
    void DoStuff(T *data) { /*...*/ }
    T *ViewStuff() { /*...*/ }
  private: 
    T *data;
}
OK, now let's assume that we have a set of helper functions that are only useful with the data in Foo while it's in Foo, and which should never be used externally but are always used whenever Foo wants to do stuff with the data. So we'll define a little nested helper class and squirrel the data away in it:
template <class T> class Foo
{
  public:
    Foo()  { /*...*/ }
    ~Foo() { /*...*/ }
    void SetStuff(T *data) { /*...*/ }
    void DoStuff(T *data)  { /*...*/ }
    T *ViewStuff() { /*...*/ }
  private:
    class DataWrapper
    {
      public:
        DataWrapper(T *data) { /*...*/ }
        ~DataWrapper() { /*...*/ }
        void HelperFunction() { /*...*/ }
        T *GetData() { /*...*/ }
      private:
        T *data;
    }
    DataWrapper *data;
}
Note that DataWrapper doesn't need to be templated; that's taken care of because it's already nested inside a templated class. Now let's imagine that SetStuff and DoStuff aren't safe methods to call all the time, and that sometimes you need to make sure that you can only use the safe methods, like viewing stuff. We just need a FooView. Fine, let's make a base class of Foo that has a copy constructor and only provides the safe methods. Then we can just take a FooView copy of Foo which we know is safe to hand over for use elsewhere. We want FooView to be the base of Foo, which is possibly slightly counterintuitive, because Foo does everything that FooView does and more besides.

template <class T> class FooView
{
  public:
    //Copy constructor to allow us to create views of a Foo
    FooView(FooView & source) { /*...*/ }
    ~FooView() { /*...*/ }
    T *ViewStuff() { /*...*/ }
  protected:
    //It doesn't make sense to create a FooView unless we give it something to 
    //copy. The descended Foo class will need a default constructor, though.
    FooView() { /*...*/ }
    class DataWrapper
    {
      public:
        DataWrapper(T *data) { /*...*/ }
        ~DataWrapper() { /*...*/ }
        void HelperFunction() { /*...*/ }
        T *GetData() { /*...*/ }
      private:
        T *data;
    }
    DataWrapper *data;

}
template <class T> class Foo : public FooView <T>
{
  public:
    Foo() { /*...*/ }
    ~Foo() { /*...*/ }
    void SetStuff(T *data) { /*...*/ }
    void DoStuff(T *data) { /*...*/ }
}

DataWrapper needs to be in the FooView class since both Foo and FooView need to understand it, but nothing else should (perhaps it's code that would be unsafe if used outside a FooView object). So far, so simple. But as soon as we try to implement anything in Foo that uses a DataWrapper, we end up in a world of pain.

Our first problem is that inside Foo, the compiler doesn't understand what a DataWrapper is. Let's add an implementation to SetStuff:
template <class T> class Foo : public FooView <T>
{
  public:
    Foo() { /*...*/ }
    ~Foo() { /*...*/ }
    void SetStuff(T * data)
    {
      DataWrapper *wrapper;
      wrapper = new DataWrapper(data);
      this->data = wrapper;
    }
    void DoStuff(T *data) { /*...*/ }
}

...which will result in the compiler error "DataWrapper was not declared in this scope". The issue is that we're in a templated class and the compiler doesn't know where to look for the definition of DataWrapper (which is also in a templated class). So let's give it a hint:

template <class T> class Foo : public FooView <T>
{
  public:
    Foo() { /*...*/ }
    ~Foo() { /*...*/ }
    void SetStuff(T *data)
    {
      FooView<T>::DataWrapper *wrapper;
      wrapper = new FooView<T>::DataWrapper(data);
      this->data = wrapper;
    }
    void DoStuff(T *data) { /*...*/ }
}

Which is pretty ugly. And leads to the baffling error "wrapper was not declared in this scope".

Huh?

But... but... that IS the declaration of wrapper!

Somehow the compiler has become so confused by the templating and whatnot that it's totally failed to parse
FooView<T>::DataWrapper *wrapper;
as a declaration. It's trying to perform some operation on wrapper as if it were already declared. I've no idea what. If you switch T for a type, the problem goes away -
FooView<double>::DataWrapper *wrapper;
works fine, apart from being a bit totally useless. So it seems that the compiler has missed the fact that
FooView<T>::DataWrapper
is a type name. Fortunately there's a keyword available to convince the compiler that no, honestly, it is a type name:

template <class T> class Foo : public FooView <T>
{
  public:
    Foo() { /*...*/ }
    ~Foo() { /*...*/ }
    void SetStuff(T *data)
    {
      typename FooView<T>::DataWrapper *wrapper;
      wrapper = new typename FooView<T>::DataWrapper(data);
      this->data = wrapper;
    }
    void DoStuff(T *data) { /*...*/ }
}

This is clearly absurd. If you're using DataWrappers in many places, your code is going to end up looking like it's been beaten to death with an ugly stick. Fortunately we can avoid all that nonsense by using a private typedef inside Foo:

template <class T> class Foo : public FooView <T>
{
  private:
    typedef typename FooView<T>::DataWrapper DataWrapper
  public:
    Foo() { /*...*/ }
    ~Foo() { /*...*/ }
    void SetStuff(T *data)
    {
      DataWrapper *wrapper;
      wrapper = new DataWrapper(data);
      this->data = wrapper;
    }
    void DoStuff(T *data) { /*...*/ }
}

And now you can just use DataWrapper inside Foo the same way as you would inside FooView - and as you probably expected to be able to use it in the first place. Obvious, eh?

EDIT - The typename keyword exists specifically to address this sort of situation, according to the description here. I guess it's one of those things that you either know (and hence will understand why you get an error about an undeclared variable from a line which you think is a declaration) or you don't and will be totally baffled by. It's not an error message that helps you towards an understanding of the source of the problem, that's for sure!

Monday 28 February 2011

Mootools and the Closure compiler

I (and Dan over at teadriven) have been battling with the Google Closure Compiler for a few days now. I say "we". As the more javascript literate Dan has been doing the vast majority of the work while I poke things with sticks and apply googlefu to trying to find solutions to problems.

The first interesting thing is that, if you search for information about how mootools works with the closure compiler, you'll find next to nothing. There's a very brief post from 2009 claiming that mootools + closure compiler "behaves quite nicely", and a couple of posts stating that you can only use advanced optimisations on closure if you've designed your code for it, and you know what you're doing. Setting the "you need to know what you're doing" part of it aside for a moment the implication is that mootools and closure don't behave quite nicely together at all. This tallies with what we've seen. Initially we were thinking we just needed to provide an externs file for Mootools and we were a little surprised that one didn't exist in the closure contribs. Then Dan started trying to make one while I blithely disappeared to try to fix my bike, which is a whole different story. A story punctuated with increasingly irate/despairing IMs popping up on my phone as the fundamental differences of opinion between Closure and Mootools started to become apparent.

We're nearly at a point where our js has been hacked to work, but it's not a case of having made Mootools and Closure work well together. And here's some of the reasons why:

  1. Javascript sucks at object orientation. Why is that a problem? Because there's no standard way to do object orientation in javascript. Mootools and Closure approach the problem differently. Closure requires javadoc tags to help it to parse the javascript correctly, and there's currently no tag that allows you to describe a mootools-style object definition. Therefore Closure doesn't like Mootools.
  2. Closure doesn't like you messing with Element. More accurately, it doesn't like you overloading the w3c Element. Mootools does overload Element (I know, technically it doesn't, it redefines it). Therefore, Closure doesn't like Mootools.
  3. There is no externs file for Mootools. If you want to use Mootools without compiling it in to your code, you need an externs file. Currently, none exist. Therefore, Closure doesn't like Mootools. Until the other problems are solved, there's no point making one which I suppose explains this.
The last problem is relatively trivial but the first two are real issues. For the first, the best way I can see around it is for the Closure compiler code to make explicit provision for the Mootools way of doing things, probably through a specific javadoc tag. I'm sure this isn't high up the priority list for The Google. We've pulled the source, though, so there's at least the chance we'll find the time to attempt to hack such a thing in. You can sort of hack your javascript into line, though.

To create a class in Mootools, you pass in an object of properties and functions to the Class function, which then spits out a new one of the things defined by the object you passed in. There's nothing there that's inherently wrong from Closures point of view, except you need to somehow tell Closure that this is a class instantiation based upon the object you pass in (it is expecting you to be a little more traditional and create a class with a constructor function which you tag with a @constructor javadoc). Closure is, therefore, confused by what "this" you're referring to inside the class. This can hackily be resolved on a case-by-case basis by liberal use of the @this javadoc tag, which is messy. It'd be much nicer to be able to tag something as a mootools-style constructor in Closure, and that would also allow Closure to understand the object inheritance tree (which is sort of broken with this hack).

As for problem two - again, I can't really find anything on the web that talks about this. I suppose nothing else (other than mootools) really tries to overload Element, so no one else has this issue. Not entirely sure why Closure protests, or how one is supposed to tell it that you're overloading/redefining Element and no, really, that's fine. I suppose going through Mootools and renaming Element as "Mooliment" or something could, potentially, be a workaround.

Slightly frustrating to have no definitive resolution to tail this post, but there's so little information out there about this problem at time of writing that even a "mootools and closure don't work well together" post seemed like a useful contribution of sorts.