Re: Joose Development
Malte Ubl
On Sun, Apr 12, 2009 at 2:50 PM, Nickolay Platonov <nick...@gmail.com> wrote:
> Hi Malte,
>
> Congratulations with launched project! Really cool, that advanced javascript
> programming techniques goes into production systems.
> I think Joose is a good candidacy to became a standard extension of native
> javascript OO (like Moose in perl).
>
> About development - the mutability branch is relatively mature and stable
> for now. It lacks some attributes features (predicate, delegating, probably
> some others),
> but in general its already suitable for real-world usage.
>
> Having a roadmap would be good, sure.
>
> I'm currently planning to spent a little time for polishing (some
> refactoring, comments, more tests etc). I'm sorry, some features are
> implemented with breaking
> backward-compat (notably class methods). I'm leaving this to your judgment -
> its generally possible to write some glue-compatibilty code, though
> migration is not complex..
Can you elaborate on the exact breakage. I leaning toward backward
compat. Is there a difference in call semantics or only with advanced
stuff like inheritance?
> My further plans are:
> - implement distributing standard (Ingy promised to help) to allow js
> modules to be installed (like perl modules with "make, make test, make
> install")
Very interesting. I know Ingy already made something similar.
> - write a full-featured bridge to Ext3 (will be released on next week)
Cool.
On a further note. Do you have recent performance numbers? How are we
doing. I'm personally not really worried about runtime performance,
but startup time is important for me and since Joose is self-hosting
that is kind of equivalent. By the way: Could you give a quick
overview of the mutability branch. Would that allow us to serialize
Joose code?
I developed a full serializer for JavaScript for the bespin project:
http://hg.mozilla.org/labs/bespin/file/e5f3bbce9abf/frontend/js/bespin/worker/worker.js
We use is to enable moving code with runtime state into workers
(threads). This might be perfect to serialize Joose code and get
parse-only startup time.
Bye
Malte
> - re-write Symbie with a new bridge
> - implement a thin wrapper around DBIx::Class (probably with JSORB)
>
> As about JS on GoogleApp+Rhino - that sounds interesting (cloud computing is
> always interesting)
> But I'm currently driven by practical need - I'd like to create the
> underlaying infrastructure (like Joose + distributing) and high-level
> framework (Symbie), which will allow
> create web-sites, which run almost completely in browsers.
>
> I'm still open here - if you have an interesting startup idea, based on
> GoogleApp+Rhino - I'd be glad to participate.
>
> Regards, Nickolay
>
>
> On Sun, Apr 12, 2009 at 12:21 PM, Malte Ubl <malt...@gmail.com> wrote:
>>
>> Hey Nickolay,
>>
>> as you knwo I currently spent most of my open.source time working on
>> bespin. However; I still have quite a lot of time left work my other
>> projects (the big work project finally went live and things settled
>> down).
>>
>> What are your immediate plans for Joose development?
>> Maybe we should have a Roadmap of what is needed for Joose 3.0
>>
>> One thing that I currently find really interesting is JS on Google App
>> Engine via Rhino. If you're interested in that topic I'm sure I could
>> get you an invite.
>>
>> Bye
>> Malte
>
>
Nickolay Platonov
I'll start with quick overview and then will return to serialization:
The sources are divided into 3 "meta-levels".
Level 1 - Joose.Proto
This level uses the same inheritance principle, as ExtJS framework. Later I had knew, that its
called "Crockford object model" (http://javascript.crockford.com/prototypal.html)
As an addition to this model, it possible to use this.SUPER() calls
Class definition at this level looks like:
TestClass = new Joose.Proto.Class('TestClass', {
isa : SuperClass,
attr1 : initValue1,
attr2 : initValue2,
method1 : function () { ... },
method2 : function () { ... }
}).c;
By default every class inherit from Joose.Proto.Object, which contains 'initialize', 'toString', 'SUPER', etc
At this level, attributes and methods are installed directly in class prototype, thus no Roles exists.
Level 2 - Joose.Managed
This level implements a set of classes, which represents "managed" properties.
Class definition at this level looks almost like Joose class:
TestClass = new Joose.Managed.Class('TestClass', {
isa : SuperClass,
does : [ Role ],
have : {
attr1 : initValue1,
attr2 : initValue2,
},
methods : {
method1 : function () { ... },
method2 : function () { ... }
},
after : {
method1 : function () { ... }
}
}).c;
At this level, attributes and methods are represented with instances of special classes. Also appears method modifiers.
Methods are installed not directly but with wrappers, which allow to use the same method in different classes - and implement Roles.
Also - there is no complex attributes on this level.
Level 3 - Joose.MetaClass, MetaRole
This level allows to use complex attributes and class definition looks like normal Joose class:
Class('TestClass', {
isa : SuperClass,
does : [ Role ]
...
});
Mutability
Any class or role, can be extended with following construction:
TestClass.meta.extend({
doesnt : [ Role ],
does : [ Role1],
havenot : [ attr1 ],
...
})
Attributes, methods, roles - can be removed or added. The change will reflect in whole inheritance hierarchy (for classes) or
through all composition relations (for roles)
Inheritance
Mutability implied a switch toward single inheritance scheme. I think Roles fully compensate this.
Its safe to inherit from lower "meta-level" - calls to SUPER are transparent.
Inheritance is now cheap operation (due to "crockford model")
Roles
Roles are implemented on Traits spec (http://www.iam.unibe.ch/%7Escg/Archive/Papers/Scha03aTraits.pdf)
They support aliasing and excluding:
Class('Creature', {
does : [{
role : Walk,
alias : {
stop : 'stopWalk'
},
exclude : [ 'stop' ]
}, {
role : Eat,
alias : {
stop : 'stopEat'
},
exclude : [ 'stop' ]
}]
});
Conflicting properties are marked with conflict markers.
Roles can be applied also to instances (with some limitations)
Class methods
and can contain any usual class builders:
Class('TestClass', {
isa : SuperClass,
does : [ Role ]
...,
my : {
have : { attr1 : initValue1, attr2 : initValue2 },
methods : { method1 : function () { ... } },
does : [ Role ]
...
}
});
they can be accessed as:
if (TestClass.my.attr1 == 'foo') TestClass.my.method1();
Startup time
As inheritance operation is now cheap, startup time for now mostly depends from how many additional roles are applied to metaclasses.
Without additional attributes roles and "depended" roles its the same as for 2.0.
With all those features though, its about twice longer (all measurements were done in FF on Ubuntu)
This can be improved if roles will be applied grouped (not in sequential order), or if the roles will be included to the sources of
appropriate classes from start.
SUPER calls (and serialization possibilty)
From start, SUPER calls on "managed" level were implemented with attached properties to wrappers.
Though this reflects on performance (each call to SUPER used up to 2 calls to arguments.callee.caller), so I switched
them to use closures, like in current version. So now the SUPER calls are at the same performance, but seriazliation
is not possible.
Though, this can be configurable, and if such performance hit is acceptable, serialization can be done (with some additional code)
Btw - about installing JS modules. Yes, Ingy already uses the approach when the JS modules are published on CPAN.
Their's sources in his approach lies near the corresponding *.pm files.
And if we'll change the "target installation" directory to something different from standard perl library, we'll get a nice, separate
JavaScript lilbrary. Thats the goal, I hope he'll do it.
Otherwise, I'm going to tweak the Module::Build::JSAN for this, it looks not complex.
Regards, Nickolay
Malte Ubl
>>
>> thanks for the interesting write up (I took the freedom to put in on my
>> blog :)
>
> Cool )
>
>> We should put in a compat mode for class methods (only when
>> constructed with classMethods builder.
>
>
> Yep, also thought about this. It can be implemented as additional
> compatibility role.
Good, we should do that. Should think about the behavior of
addClassMethod, too, but that is of less importance. Accessing
arguments is also expensive and makes optimizations by TraceMonkey,
etc. impossible.
>> Is every method call now a call to a wrapped method because it might call
>> SUPER?
>> There is a dirty trick around this by calling toString on the method
>> and looking for SUPER to find out whether the overhead is neccessary.
>
> I thought toString dont works in IE6,7? The overhead here is minimal - its
> only a single call to 'closured' function
> with some properties "shuffling", should be ok here.
But a cost on every call right? In my experience
Function.prototype.toString/toSource works perfectly on all of our
target platforms.
>> If methods retain their method object we could provide for a
>> serializable form which knows how to create the closure at runtime.
>
> Yep, its possible. But I just thought about a 2nd limiting factor - file
> size.
> It can grow significantly, we need to roughly estimate it first somehow..
Should be now problem with minimization and especially gzipping.
>> On a related note:
>> I developed a very simple meta class that instantiate Joose classes
>> lazily on first instantiation. I'll let it rest for a while and then
>> put it into core.
>
> Really cool idea - it can dramatically reduce startup time for Ext bridge.
Its really simple. You basically postpone the call to
initializeFromProps to as late as possible.
Cheers,
Malte
> Regards, Nickolay
>
>
>
>>
>>
>> Bye
>> Malte
>>
>> On Tue, Apr 14, 2009 at 11:15 AM, Nickolay Platonov <nick...@gmail.com>
Jan Van Lysebeth
Has anybody been working on serialization yet?
I would like to use it for my classbrowser based mini ide. The goal of
the ide is to do live client-side development in the classbrowser and
when finished allow to export the current state of the meta model as
javascript files. Are the reflective capabilities of the joose
mutability branch suited for this? Or is this beyond what is possible?
Jan, a VisualWorks fan :)
On Apr 14, 11:44 pm, Malte Ubl <malte....@gmail.com> wrote:
>
> >> >> Hey,
>
> >> >> On Sun, Apr 12, 2009 at 2:50 PM, Nickolay Platonov
>
> read more »
Malte Ubl
some of the work on the mutability branch goes in this direction. I
also did a lot of work for bespin that includes migrating
state+functions to worker threads at runtime.
The thing is: You can do it, but only if the constraint is that none
of the methods are closures and that we have custom serializations in
the getter/setter meta classes (which should be easy).
Cheers
Malte
Nickolay Platonov
Hi all,
Has anybody been working on serialization yet?
I would like to use it for my classbrowser based mini ide. The goal of
the ide is to do live client-side development in the classbrowser and
when finished allow to export the current state of the meta model as
javascript files. Are the reflective capabilities of the joose
mutability branch suited for this? Or is this beyond what is possible?
Do you need to maintain the execution state or only class definition information?
Nickolay
Jan Van Lysebeth
certainly please my VisualWorks fixation :)
No seriously, my question was intended to get an impression of how
feasible my ideas are. Malte's response encourages me to go forward.
So I will focus on serialization before undertaking more ambitious
goals like saving execution state.
Thanks for the respons.
Cheers,
Jan
On Jun 2, 5:38 pm, Nickolay Platonov <nickol...@gmail.com> wrote:
> On Tue, Jun 2, 2009 at 7:22 PM, Jan Van Lysebeth
Malte Ubl
for a generic JS serializer (knows nothing about Joose) see
http://bitbucket.org/malde/bespin-malde/src/tip/frontend/js/bespin/worker/worker.js
Nickolay Platonov
I would like to use it for my classbrowser based mini ide. The goal of
the ide is to do live client-side development in the classbrowser and
when finished allow to export the current state of the meta model as
javascript files. Are the reflective capabilities of the joose
mutability branch suited for this? Or is this beyond what is possible?
Ah, I re-read this and got your idea - you want to turn ClassBrowser to ClassDesigner. Cool idea.
Nickolay
Malte Ubl
just wanted to let you know that as I do a lot of bespin development
right now, as soon as you somebody has a textarea that lets you edit
code, I can put something nice on top :)
Cheers
Malte
Jan Van Lysebeth
integrate and since only small code fragments are edited in the
classdesigner / ide, it performs well enough.
It would be cool to use Bespin in the future. So when I have something
working, which won't be as soon as I would like as I only have a few
hours a week to work on the ide, I hope your offer still stands ;-)
Cheers,
Jan
On Jun 3, 2:02 pm, Malte Ubl <malte....@gmail.com> wrote:
> Hey All,
>
> just wanted to let you know that as I do a lot of bespin development
> right now, as soon as you somebody has a textarea that lets you edit
> code, I can put something nice on top :)
>
> Cheers
> Malte
>
> > On Tue, Jun 2, 2009 at 7:22 PM, Jan Van Lysebeth <jan.vanlyseb...@gmail.com>