Hi Robert This is very helpful. Thank you.
Steve On Wed, Jun 23, 2010 at 9:58 AM, Robert Krahn < [email protected]> wrote: > Hi, Steve -- > > What are the main organizational concepts in Lively? What are Areas, > Workspaces, Packages and Classes? > > I am somewhat bemused by the way Javascript builds class-instance > behaviour on top of a prototype system (although it's been a while since I > read much about it, so I might be mistaken). Does Lively retain the idea of > classes or is it purely a prototype system? > > > *Modules* > * > * > The main package entity for source cod in Lively is what we call a module. > A module integrates several things: > - It has a name and this name is used as a namespace when the module is > loaded > - A module can be loaded asynchronously on demand simply by referencing > them with their name > - A module include class definitions (also function and object definitions > but we want to stick to the class concept whenever possible) > (Note: Since a module namespace can be currently extended from anywhere, > modules do not enforce encapsulation) > > > *Module Example* > > module('lively.ide').requires('lively.Tools', > 'lively.Ometa').toRun(function() { > // Code depending on lively.Tools and lively.Ometa > }); // end of module > > This definition does two things: > > a) Define the module lively.ide. The module can then be required from > somewhere else: > require('lively.ide').toRun(function() { new > lively.ide.SystemBrowser().open() }) > Evaluating this will let the system: > 1. Check if lively.ide is loaded. If not then the module name is translated > to an URL: {Config.codeBase}/lively/ide.js. That URL will be used to load > the file ide.js asynchronously. * > 2. When the file is loaded run the code of toRun() > > b) Define the namespace lively.ide. > That means that if the module is there you can access it's members in > JavaScript. For example the class lively.ide.SystemBrowser is such a member. > ** > > For more information (module-file-mapping, how to get started in the wiki, > etc.) please read: > > http://lists.hpi.uni-potsdam.de/archive/lively-kernel/2010-April/000347.html > > http://lists.hpi.uni-potsdam.de/archive/lively-kernel/2010-April/000360.html > > > *Classes* > * > * > Lively implements it's own class system implementation that was inspired by > Prototype's class system. > > e.g. > Object.subclass('Foo', { > method: function() { return 23 }, > }); > new Foo().method() // --> 23 > > > *IDE* > * > * > *Lively implements a complete JavaScript IDE, it's main part is the System > code browser. It can be opened using the WorldMenu.* > * > * > > A friend suggested that Lively might be a good environment to learn > Javascript but I'd like to have a better idea of how people manage > dependencies among various libraries. It seems that managing a pool of *.js > files also needs to represented. Does Lively let you mix and match other > Javascript libraries? If so, would it be possible to add visual tools to > help with this or is the fundamental browser model too restrictive for that? > > > It's definitely better to learn JavaScript in Lively than using in-place > HTML scripting since Lively gives you immediate feedback (evaluate any > expression in a Workspace or any other TextMorph with CMD+d (CMD+p to print > the result). > > Managing files: see modules. > > Best, > Robert >
_______________________________________________ lively-kernel mailing list [email protected] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
