Mutability branch

[Nickolay Platonov]

Hello all,

I'm glad to announce, that mutability branch reached relatively mature and stable state.
You can try it out from http://joose-js.googlecode.com/svn/branches/mutability/

New features in this branch:

- Roles system implementation, satisfying Traits spec (link1, link2)
an example: http://www.extpaste.com/#2186

- mutability (any change in class/role propagates through all inheritance/composition relations)
- built-in singleton symbiont classes
- various namespace and dependencies handling features (were ported from "dependencies branch")

This branch has all chances to eventually become Joose 3.0, meanwhile early adopters welcome )

Regards, Nickolay

[Jan Van Lysebeth]

Hello Nickolay,

I am trying to use the classbrowser example as a simple IDE.
While looking for removeAttribute, removeMethod and removeRole, I
noticed this already exists in the mutability branch.
So I'm upgrading, but I can't get getter/setter generation for
attributes to work.
This is what I do:

Class("visualjoose.classbrowser.Selection", {
have: {
module: {is: 'rw'},
clazz: {is: 'rw'},
category: {is: 'rw'},
element: {is: 'rw'}
}
...
});

I instantiate a selection like this: var sel = new
visualjoose.classbrowser.Selection();
Then 2 things I don't understand happen:
* sel.getModule and sel setModule are undefined
* sel.module contains {is: 'rw'} instead of null

Am I doing something wrong?

There is a good chance I screwed up Joose when inventing my own
loadComponents. I based my loadComponents on the one in 2.0 and used
the Components.JS file in the root of the mutability branch for
knowing which javascript files to generate a script tag for.
Is loadComponents replaced by the grouped dependency loading mechanism
you are working on? I haven't tried it out yet, because I use Rhino on
the server side.

Two other things I changed without being sure I replaced them
correctly are:
*I replaced the "has" attribute builder with the "have" builder.
*Module("aModuleName") doesn't exist anymore? So I don't use it
anymore and instead use Class("aModuleName.aClassName")


Thanks for any help and the cool project that Joose is.

Jan

On Apr 13, 11:51 am, Nickolay Platonov <nickol...@gmail.com> wrote:
> Hello all,
>
> I'm glad to announce, that mutability branch reached relatively mature and
> stable state.

> You can try it out fromhttp://joose-js.googlecode.com/svn/branches/mutability/

>
> New features in this branch:
>
> - Roles system implementation, satisfying Traits spec

> (link1<http://www.iam.unibe.ch/%7Escg/Research/Traits/>,
> link2 <http://www.iam.unibe.ch/%7Escg/Archive/Papers/Scha03aTraits.pdf>)

> an example:http://www.extpaste.com/#2186
>
> - mutability (any change in class/role propagates through all
> inheritance/composition relations)
> - built-in singleton symbiont classes
> - various namespace and dependencies handling features (were ported
> from "dependencies

> branch<http://groups.google.com/group/joose-js/browse_thread/thread/48cfcf01...>

[Nickolay Platonov]

Hi Jan,

I'm very glad you decided to try the mutability branch, and will be happy to provide a help for it.

On Tue, May 26, 2009 at 8:17 PM, Jan Van Lysebeth <jan.van...@gmail.com> wrote:

Class("visualjoose.classbrowser.Selection", {
       have: {
               module: {is: 'rw'},
               clazz: {is: 'rw'},
               category: {is: 'rw'},
               element: {is: 'rw'}
       }
       ...
});

I instantiate a selection like this: var sel = new
visualjoose.classbrowser.Selection();
Then 2 things I don't understand happen:
* sel.getModule and sel setModule are undefined
* sel.module contains {is: 'rw'} instead of null

Am I doing something wrong?

You are using new 'have' builder here, which creates a basic attribute. Currently there are basic attributes
and advanced attributes. Basic attributes only install their's value into prototype (thats why sel.module contains {is: 'rw'})
and thats all - no accessors are generated. They can be used as lightweight attributes when no advanced features are required.

To get the accessors use 'has' builder. Though note, that additional features for advanced attributes are provided in
separate distribution - JooseX-Attribute (there are Lazy and Trigger roles)

There is a good chance I screwed up Joose when inventing my own
loadComponents. I based my loadComponents on the one in 2.0 and used
the Components.JS file in the root of the mutability branch for
knowing which javascript files to generate a script tag for.
Is loadComponents replaced by the grouped dependency loading mechanism
you are working on? I haven't tried it out yet, because I use Rhino on
the server side.

 

Well, loadComponents functionality were mostly used during testing and were delegated to the Test.Run.
Test.Run loads all needed files, based on information from Components.JS. (Test.Run demo link)
In "production" cases I'm using concatenated version (/lib/Task/Joose/core.js or /inc/Task/Joose/Stable.js)
 

*Module("aModuleName") doesn't exist anymore? So I don't use it
anymore and instead use Class("aModuleName.aClassName")

Module("aModuleName") does exists and works the same way, though you may just write Class("aModuleName.aClassName"), yes.
Even more - later you may write Class("aModuleName") and will receive an expected result.
Also Modules can be seamlessly promoted to Class.
 

Some information about Test.Run, which is a current testing platform (written on Joose :).
Its an installable JSAN distribution, which depends on several others distributions.
For now JSAN client shell is not usable, so it can only be installed manually.

If you have any questions feel free to ask.

Regards, Nickolay

[Jan Van Lysebeth]

Using /lib/Task/Joose/core.js instead of loadComponents and JooseX-
Attribute solved my attribute issues.

Thanks

On May 26, 7:53 pm, Nickolay Platonov <nickol...@gmail.com> wrote:
> Hi Jan,
>
> I'm very glad you decided to try the mutability branch, and will be happy to
> provide a help for it.
>

> On Tue, May 26, 2009 at 8:17 PM, Jan Van Lysebeth <jan.vanlyseb...@gmail.com

>
>
>
> > wrote:
>
> > Class("visualjoose.classbrowser.Selection", {
> >        have: {
> >                module: {is: 'rw'},
> >                clazz: {is: 'rw'},
> >                category: {is: 'rw'},
> >                element: {is: 'rw'}
> >        }
> >        ...
> > });
>
> > I instantiate a selection like this: var sel = new
> > visualjoose.classbrowser.Selection();
> > Then 2 things I don't understand happen:
> > * sel.getModule and sel setModule are undefined
> > * sel.module contains {is: 'rw'} instead of null
>
> > Am I doing something wrong?
>
> You are using new 'have' builder here, which creates a basic attribute.
> Currently there are basic attributes
> and advanced attributes. Basic attributes only install their's value into
> prototype (thats why sel.module contains {is: 'rw'})
> and thats all - no accessors are generated. They can be used as lightweight
> attributes when no advanced features are required.
>
> To get the accessors use 'has' builder. Though note, that additional
> features for advanced attributes are provided in
> separate distribution -

> JooseX-Attribute<http://github.com/SamuraiJack/JooseX-Attribute/tree>(there

> are Lazy and Trigger roles)
>
> There is a good chance I screwed up Joose when inventing my own
>
> > loadComponents. I based my loadComponents on the one in 2.0 and used
> > the Components.JS file in the root of the mutability branch for
> > knowing which javascript files to generate a script tag for.
> > Is loadComponents replaced by the grouped dependency loading mechanism
> > you are working on? I haven't tried it out yet, because I use Rhino on
> > the server side.
>
> Well, loadComponents functionality were mostly used during testing and were
> delegated to the Test.Run.
> Test.Run loads all needed files, based on information from Components.JS.

> (Test.Run demo link <http://jsan.symbie.org/Joose3/mutability/t/>)

> In "production" cases I'm using concatenated version
> (/lib/Task/Joose/core.js or /inc/Task/Joose/Stable.js)
>
> *Module("aModuleName") doesn't exist anymore? So I don't use it
>
> > anymore and instead use Class("aModuleName.aClassName")
>
> Module("aModuleName") does exists and works the same way, though you may
> just write Class("aModuleName.aClassName"), yes.
> Even more - later you may write Class("aModuleName") and will receive an
> expected result.
> Also Modules can be seamlessly promoted to Class.
>
> Some information about Test.Run, which is a current testing platform
> (written on Joose :).
> Its an installable JSAN distribution, which depends on several others
> distributions.
> For now JSAN client shell is not usable, so it can only be installed

> manually<http://groups.google.com/group/joose-js/browse_thread/thread/ee21fd92...>
> .

[Nickolay Platonov]

So, class browser works on mutability branch? Good news.

Nickolay

[Jan Van Lysebeth]

Not yet, I'm upgrading the classbrowser code now.

On May 27, 2:43 pm, Nickolay Platonov <nickol...@gmail.com> wrote:
> So, class browser works on mutability branch? Good news.
>
> Nickolay
>

> On Wed, May 27, 2009 at 2:16 AM, Jan Van Lysebeth <jan.vanlyseb...@gmail.com

[Jan Van Lysebeth]

With the help of Nickolay the classbrowser is working again (revision
823).

Some notes:
*all html is in 1 file because Joose.SimpleRequest no longer exists
*Joose is loaded by 1 script tag pointing to lib/Task/Joose/core.js
*the html file has 2 script tags pointing to your github account for
the JooseX.Attribute stuff.
*these changes make it possible run the classbrowser.html file in a
browser. This makes developing smooth and hides that I don't know
anything about JSAN :-)

The classbrowser more or less works. The biggest problem are the
INNER, SUPER, SUPERARG,... methods. They show up as blank lines in the
methods selectbox. They should be handled differently by the
classbrowser since these methods are listed by Class.methods as simple
function objects instead of MethodModifiers. But I haven't implemented
such behavior yet.

Thanks again Nickolay,

Jan

On May 28, 1:00 am, Jan Van Lysebeth <jan.vanlyseb...@gmail.com>