Last Comment Bug 755963 - Fix unfortunate design decision of tab.attach
: Fix unfortunate design decision of tab.attach
Status: NEW
:
Product: Add-on SDK
Classification: Client Software
Component: General (show other bugs)
: unspecified
: All All
: P2 normal (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://github.com/mozilla/addon-sdk/...
: 697590 (view as bug list)
Depends on:
Blocks: sdk/tabs
  Show dependency treegraph
 
Reported: 2012-05-16 17:13 PDT by Irakli Gozalishvili [:irakli] [:gozala] [@gozala]
Modified: 2015-02-20 12:14 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Irakli Gozalishvili [:irakli] [:gozala] [@gozala] 2012-05-16 17:13:28 PDT
Unfortunate design choice of `Tab` API `tab.attach()` makes tabs aware of `page-mods`. It would be a much better if we had `pageMod.attachTo(documentOwner)` where `documentOwner` could be anything that has namespaced `document` property a la: 

`owner(documentOwner).document`

Maybe we still can implement new API and deprecate old one, which later can be removed (In 2.0 maybe) ?
Comment 1 Alexandre Poirot [:ochameau] 2012-05-28 08:55:01 PDT
(In reply to Irakli Gozilalishvili [:irakli] [:gozala] from comment #0)
> Unfortunate design choice of `Tab` API `tab.attach()` makes tabs aware of
> `page-mods`.

I'm not sure it is very relevant to design our public API based on internal code constraints. We should focus on exposing an API that make sense, and avoid making it more important to ease our implementation.

I can buy that tab.attach may not be the best API, but in bug's comment I'm only reading ease of implementation motivation.
Comment 2 Irakli Gozalishvili [:irakli] [:gozala] [@gozala] 2012-05-30 05:57:34 PDT
(In reply to Alexandre Poirot (:ochameau) from comment #1)
> (In reply to Irakli Gozilalishvili [:irakli] [:gozala] from comment #0)
> > Unfortunate design choice of `Tab` API `tab.attach()` makes tabs aware of
> > `page-mods`.
> 
> I'm not sure it is very relevant to design our public API based on internal
> code constraints. We should focus on exposing an API that make sense, and
> avoid making it more important to ease our implementation.
> 
> I can buy that tab.attach may not be the best API, but in bug's comment I'm
> only reading ease of implementation motivation.

Did I mention because it's easier to implement?

Point I'm trying to make is

tab.attach(mod)
target.attach(mod)

is less natural and less ergonomic than

mod.attach(target)

It's just natural to learn about `mod` (modification) abstraction and
than apply that knowledge to all (modification) targets (anything that
wraps document).

At the moment `tab` is exception and people ask for more exceptions like
it. It's better to provide general re-usable solution that involves less
learning curve. Every new (modification) target we'll add will just
inherently work the same.

Questionable ease of implementation is just a side effect of better composable
components.
Comment 3 Irakli Gozalishvili [:irakli] [:gozala] [@gozala] 2012-05-30 06:03:16 PDT
Also linked content-script JEP https://github.com/mozilla/addon-sdk/wiki/JEP-Content-scripts may be more generic solution for the problems this attempts to solve.
Comment 4 Erik Vold [:erikvold] (please needinfo? me) 2015-02-20 12:14:31 PST
*** Bug 697590 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.