-
Notifications
You must be signed in to change notification settings - Fork 0
Clean Lively Core
What’s really core? What’s still from LK1 and can be removed from our LK2-CORE repo? The following modules/files are at least suspicious and might want to be deleted...
-
lively.data
-
lively.OldModel
-
lively.NoMoreModels
-
lively.Data
-
lively.NewMorphicCompat
-
lively.Migration
-
lively.ObjectMigration
-
lively.morphic.CompatLayer
-
Global.DisplayThemes in lively.morphic.Styles
-
cop/MiniBase.js and cop/miniprototype.js
-
cop/Experiments.js
-
lively.morphic.EventExperiments
-
lively.morphic.WidgetsAddOns
-
ometa/prototype-fix.js
-
ometa/Workspace.js
- lively.morphic.AdditionalMorphs > 1750 LOC, stupid name
- lively.morphic.Core, name could indicate that it defines Morph, World, Box, List, .. “CoreMorphs”? And Script, FunctionScript should be in another module
- lively.morphic.Events > 1750 LOC, separate FileUploader, maybe we can have this module define EventHandler, ScrollableTrait, EventSimulator, while Morph, Text, List, and other widgets implement their event handling in their modules (less extensions, more “complete” class defs)
- lively.persistence.ObjectExtensions vs. lively.morphic.Serialization
- Base.js: create a module for modules and namespaces and another one for Lively's class-system
LK 1 vs. LK 2: Config.isNewMorphic - clean up: remove conditionals and use true-branch, remove lively/morphic.js
Configs: need to be cleaned up, maybe merge localconfig and defaultconfig
Suites: Do we want to have module suites like ‘lively.morphic.Complete’ and test suites like ‘tests.Morphic’ has been?
Class-side methods: Currently, we use Object.extend(classConstructor, {...}) to define static methods without categorization. How about adding class-side method definition to our class system? Might make instance-/class-side method defs easier readable (tool-support?) and categorization will help as well...