0.15 strategic vision
Locked
 
|
Hello!
0.14 is not yet out, but is planned in end of the year, so I was thinking about 0.15. After experiencing pains a few of people here has with composing the Amber code pieces together in last days, I think I should set strategic goals for 0.15 release, scheduled on Apr 1st (hopefully 0.15 won't end up as a joke), this goal being Painless package / dependency management, reusability and modularity There are things that are suboptimal in this field, while people are eager to use Amber in big which necessitates modularization and reuse: - Amber packages only contain implicit dependencies (packages with superclasses and/or extended classes must be loaded prior the package itself). But a package may need to explictly list "imports" it want to use, primarily among external JS libraries. Packages should be allowed to specify explicit dependencies. - To compile .st into .js in cli, as well as to run test suites of a project in cli, it is now needed to hand-customize Gruntfile.js. This should not be needed. - An app itself defines what to load while in production / while in development in deploy.js / devel.js files. Those need to be hand-customized as well if there are new libraries / new packages. It should be possible to manage contents of these files by more intuitive fashion in IDE itself. - There are a few little perks that may need better interface. As an example, renaming package, moving package to another namespace, and loading a not-yet loaded package should be possible from IDE. This can greatly enhance creating and/or using Amber libraries. The general vision is, people could create / use modules in Amber in IDE itself, with as little pain as possible and ideally without touching text editor because deploy.js / devel.js / Gruntfile.js* / local.amd.json needs some change. Herby * Gruntfile.js should not be changed from IDE, that can break a lot of things, especially when user added its own tasks to it / customized it itself, but it should be made so it does not need to change for everyday infrastructure changes to work -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
On Mon, Dec 15, 2014 at 7:41 PM, Herby Vojčík <[hidden email]> wrote: Hello! Yes, this is smart. As this will be done in Helios, do we have someone able to do changes in there? Phil
--- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Blog: http://philippeback.be | Twitter: @philippeback High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
[hidden email] wrote: > On Mon, Dec 15, 2014 at 7:41 PM, Herby Vojčík <[hidden email] > <mailto:[hidden email]>> wrote: > > Hello! > > 0.14 is not yet out, but is planned in end of the year, so I was > thinking about 0.15. After experiencing pains a few of people here > has with composing the Amber code pieces together in last days, I > think I should set strategic goals for 0.15 release, scheduled on > Apr 1st (hopefully 0.15 won't end up as a joke), this goal being > > Painless package / dependency management, reusability and modularity > > There are things that are suboptimal in this field, while people are > eager to use Amber in big which necessitates modularization and reuse: > > - Amber packages only contain implicit dependencies (packages > with superclasses and/or extended classes must be loaded prior the > package itself). But a package may need to explictly list "imports" > it want to use, primarily among external JS libraries. Packages > should be allowed to specify explicit dependencies. > > - To compile .st into .js in cli, as well as to run test suites > of a project in cli, it is now needed to hand-customize > Gruntfile.js. This should not be needed. > > - An app itself defines what to load while in production / while > in development in deploy.js / devel.js files. Those need to be > hand-customized as well if there are new libraries / new packages. > It should be possible to manage contents of these files by more > intuitive fashion in IDE itself. > > - There are a few little perks that may need better interface. As > an example, renaming package, moving package to another namespace, > and loading a not-yet loaded package should be possible from IDE. > This can greatly enhance creating and/or using Amber libraries. > > The general vision is, people could create / use modules in Amber in > IDE itself, with as little pain as possible and ideally without > touching text editor because deploy.js / devel.js / Gruntfile.js* / > local.amd.json needs some change. > > > Yes, this is smart. As this will be done in Helios, do we have someone > able to do changes in there? Not only in Helios. But no, we do not have such person. That is in fact not that smart. > Phil > > > Herby > > * Gruntfile.js should not be changed from IDE, that can break a lot > of things, especially when user added its own tasks to it / > customized it itself, but it should be made so it does not need to > change for everyday infrastructure changes to work -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
«
Return to Amber Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |