#1403 web::WebMod as a mixin vs an abstract const class

msl Fri 28 Jan 2011

Query

Is there any reason it's implemented as abstract const class WebMod rather than const mixin WebMod?

I've done a (full rather than just compile(1)) build from source with the class updated and everything (that's expected to (2,3)) works.

On top of that, all examples (both web and js) work as expected, as does my own local code.

Background

The reason this came about is trying to extend Weblet as a custom mixin:

mixin ExtendedWeblet : Weblet {
    override Void onService() { /* do stuff */ }
}

But then in order to use that mixin with WispService it needed to extend both WebMod as well as my ExtendedWeblet (to be assigned to WispService.root):

const class ExtendedWebMod : WebMod, ExtendedWeblet {
    /* Custom stuff */
}

However, the call to Weblet.onService then routes through the WebMod to Weblet.onService, unless I again override it:

const class ExtendedWebMod : WebMod, ExtendedWeblet {
    /* Custom stuff leveraging ExtendedWeblet */
    override Void onService() {
        ExtendedWeblet.super.onService
    }
}

Which isn't the end of the world - but does seem a bit noisier from the final implementation than should really be necessary.

Martin

(sorry for the footnotes - I'll follow them up in separate threads if I can sort fixes)

Footnotes

  1. It'd actually be good to be able to specify tests should be run via adm/bootstrap.fan.
  2. There's an issue with testSys::DateTimeTest.testNowUnique (seems intermittent based on the scheduling of actors used with timestamps)
  3. There's an issue with testCompiler::EnvTest.test
    -- Run:  testCompiler::EnvTest.test...
    WARN: cannot init Sys.curEnv
    sys::UnknownPodErr: util
        at fan.sys.UnknownPodErr.<init>(UnknownPodErr.java:39)
        at fan.sys.UnknownPodErr.make(UnknownPodErr.java:25)
        at fan.sys.UnknownPodErr.make(UnknownPodErr.java:22)
        at fan.sys.Pod.readFPod(Pod.java:159)
        at fan.sys.Pod.doFind(Pod.java:65)
        at fan.sys.Pod.find(Pod.java:46)
        at fanx.util.TypeParser.find(TypeParser.java:87)
        at fanx.util.TypeParser.load(TypeParser.java:67)
        at fan.sys.Type.find(Type.java:44)
        at fan.sys.Sys.initEnv(Sys.java:413)
        at fan.sys.Sys.<clinit>(Sys.java:212)
        at fanx.tools.Fan.execute(Fan.java:28)
        at fanx.tools.Fan.run(Fan.java:250)
        at fanx.tools.Fan.main(Fan.java:288)

brian Fri 28 Jan 2011

The reason I made it a class was mostly just future proofing in case we ever needed to add to state in the future (and that was because at various times of its life that class has had fields). I figured worse comes to worse it is pretty easy to delegate to other weblets, so I figured it was a decent trade-off.

Login or Signup to reply.