Latest topics - outsider reflex

Why I'm using eval() instead of others?

参考：AMOエディタ権限剥奪きますた

Hello,

Surely I wrongly believed that the policy is flexible for cases, because Tree Style Tab was in the "recommended" list actually. When the policy was changed (to be applied completely for any addons), it had to be removed from the list quickly. This is not a cynicism, I'm really worrying that double standard will make developers confused.

In fact I had not reviewed addons as an editor yet, so this is nonsensically thing, but if I still can talk about this, I didn't mean to accept any addons include eval()s without reviewing. When there are alternative safer way, I thought that recommend him to rewrite his codes. I just told about cases which are not alternated by other ways.

Anyway, I agree to the decision that you've removed me from the group. I had no actual achievement as an editor (there is zero review! I'm very sorry.), instead, I'm all mouth. That's that. I'll still use AMO as an addon author, to put old XPI files, and I possibly move existing versions in the AMO to the beta channel. I think that AMO is really really great work. Editors also.

regards,

P.S.

Can I explain again the reason why I'm using eval() to override existing functions instead of other ways? Of course I use custom DOM events or other safe way when they are available. Following topic is about cases which don't fire custom events. In other words, I explain why I don't like replacing of existing functions by "originalFunction.apply(this, arguments)".

In old days I developed an all-in-one style addon named "Tabbrowser Extensions (TBE)" for Firefox 1.5 and older versions. It was one of major addons about tabbed browsing enhancements, until Tab Mix Plus appeared. In the addon, I aggressively replaced many internal functions of Firefox itself, like:

var origFunc = gBrowser.moveTabTo;
gBrowser.moveTabTo = function() {
  var result = origFunc.apply(this, arguments);
  // some post-process for the moved tab
  return result;
};

Yes, it is one of ways recommended in the entry http://adblockplus.org/blog/five-wrong-reasons-to-use-eval-in-an-extension for injecting some operations before/after the original function.

However, then I frequently suffered from compatibility problems with other addons around tabs, because they used eval() to inject their tiny codes to existing (Fireflx's original) functions, like:

eval("gBrowser.moveTabTo = "+gBrowser.moveTabTo.replace(
  "tab = ",
  "doSomething(); $&"
));

As you know, replacing of functions break addons which inject codes by eval() like above. So I had to choose how to solve this problem, from two ways: 1) import and merge the function of the addon conflict with TBE, 2) use eval() instead of replacing of functions. There was no other choice. To make another addon compatible to mine, it had to be re-written without eval(), but it can't be done in some cases, because the feature surely required injected codes to existing functions. I couldn't make mine compatible to the addon without eval(). I disliked eval(), then I chose "1". In the result, TBE became very very fat addon and I couldn't continue to develop it by me alone anymore. I abandoned it.

I can't force users to forbid using addons which depend on eval(). On the other side, I cannot merge too many features to my own addon because fat and huge project will annoy me. From both reasons "make my addon compatible with the addon" and "keep my addon simple (without extra features)", now I'm using eval()s to inject just minimal codes.

Safety margin about compatibility to other tab-related addons is one of core values of Tree Style Tab and other my addons developed after TBE. When I get reports of compatibility problems with other addons, I try to make mine compatible to others if at all possible (and, of course, for compatibility some my addons provide APIs for others.) If there were only "clean" ways (DOM events, Object.prototype.watch(), etc.) TST were far from satisfactory for tab addicts. Because I'm also using many other tab-related addons (not developed by me), if it doesn't work others, I also won't use TST. Just for making my addons compatible to existing and future addons, I chose eval().

If there were many other custom events for bookmark commands, new tab commands, etc., I won't use eval()s. XBL, CSS hacks also. However, margins for extending UIs (unused boxes etc.) are getting removed from Firefox, because "they eat the RAM, they make the startup process slowly". Only to adding extra elements to tabs, I had to use custom XBL at risk of compatibility problems with third party's themes.

Firefox is getting hard to be extended for me (and my addons). My addon was listed to "recommended", and people say "update it for latest Firefox". There is no way to provide features of my addon without dangerous way. That is my situation.

今evalを理由に審査を蹴られるのであっても、その代替となるより安全な手段が提供されるのであれば、迷わずそっちに乗り換えたいとは思ってる。問題は、独自のXBLを提供するなどの「危ない」事をしなければやりたい事を実現できないような、拡張機能から触れる伸び代の部分がどんどんなくなってるという事だ。それどころか、起動速度が落ちるからという理由でFUELがばっさり切られたように、今ある必要な物すらどんどん切られていっている。W3Cですら、テーブルレイアウトを必要とする人達のニーズにある程度答えられるような、position: absoluteのような仕組みを仕様に取り入れていたというのに。そういう現実を抜きにして、この話は語れないと思う。

あと先方から補足があったけど、曰く、AMO Editorsグループから外した直接の理由は確かに「ポリシーに同意していないから」だけれども、活動してないエディタを外す事自体はよくあることだそうで、ポリシー云々のことが無くてもレビュー実績0の自分はいずれ外されてただろうとのことです。