GNU
/
easejs
1
0
Fork 0
Code Releases Activity

README.md et. al. restructuring 

There is now only one README* file---README.md.  Other files have been
renamed (e.g. README.hacking=>HACKING), or consolidated.
master
Mike Gerwitz 2015-08-23 00:15:48 -04:00
parent 4a61781701
commit 62f7e0111a
No known key found for this signature in database
GPG Key ID: F22BB8158EE30EAB
5 changed files with 37 additions and 86 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

0
README.hacking → HACKING
View File

51
README
View File

@ -1,51 +0,0 @@
Configuring ease.js
*******************
Copyright (C) 2013, 2014 Free Software Foundation, Inc.
This file is part of GNU ease.js.
Copying and distribution of this file, with or without modification, are
permitted in any medium without royalty provided the copyright notice and
this notice are preserved. This file is offered as-is, without warranty
of any kind.
This file contains information on configuring and building GNU ease.js; for
information on using the library, please see the Markdown-formatted README.md
file or the Texinfo manual.
Installing
==========
For information on installing ease.js on your system, see INSTALL.
Alternatively, you may install the software using npm by issuing the
following command:
$ npm install easejs
Configuring
===========
If your distribution contains a `configure' file in the project root, you
may jump immediately to INSTALL.
Otherwise, you likely have the sources as they exist in the project
repository, which does not contain the generated `configure' script; you
may generate it by issuing the following command:
$ autoreconf -fvi
Please note that certain files (such as AUTHORS, NEWS, and ChangeLog) are
generated as part of the `dist' target and do not exist as part of the
repository.
Hacking
=======
For information on hacking and contributing to GNU ease.js, please see
README.hacking.

6
README.md
View File

@ -1,5 +1,5 @@
<!--
Copyright (C) 2010, 2011, 2013, 2014 Free Software Foundation, Inc.
Copyright (C) 2010, 2011, 2013, 2014, 2015 Free Software Foundation, Inc.
This file is part of GNU ease.js.
@ -57,6 +57,10 @@ with existing prototypes, allowing the developer to choose whether or not
they want to use "classes".
## Building and Installation
See [INSTALL](./INSTALL).
## License
GNU ease.js is free software: you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software

25
README.todo
View File

@ -1,25 +0,0 @@
# -*-org-*-
# TITLE: GNU ease.js TODOs
TODO tasks can be found in the bug tracker at
http://easejs.org/bugs. Below is a list of the glaring issues that may
be found at first glance.
* TODO Coupling
During the beginning of the project, all modules were represented as
object literals, which is similar to the concept of a
Singleton. This satisfied the needs of the early project, but it
soon evolved far past its original design and resulted in a tightly
coupled system that was difficult to maintain, add to and
test. Refactoring into prototypes is ongoing.
* TODO Performance tests
Performance tests need to be written for every aspect of the
system. They will ultimately be graphed to show the relative
performance across versions of the software.
* TODO Closure compiler warnings
Certain warnings are suppressed. Figure out the best way to resolve
them without suppressing them, unless suppression is truely the best
option.

41
README.traits → TODO
View File

@ -1,6 +1,29 @@
# -*-org-*-
# TITLE: GNU ease.js Traits
# TITLE: GNU ease.js TODOs
TODO tasks can be found in the bug tracker at
http://easejs.org/bugs. Below is a list of the glaring issues that may
be found at first glance.
* TODO Coupling
During the beginning of the project, all modules were represented as
object literals, which is similar to the concept of a
Singleton. This satisfied the needs of the early project, but it
soon evolved far past its original design and resulted in a tightly
coupled system that was difficult to maintain, add to and
test. Refactoring into prototypes is ongoing.
* TODO Performance tests
Performance tests need to be written for every aspect of the
system. They will ultimately be graphed to show the relative
performance across versions of the software.
* TODO Closure compiler warnings
Certain warnings are suppressed. Figure out the best way to resolve
them without suppressing them, unless suppression is truely the best
option.
* Traits [0/8]
The trait implementation is not yet complete; this is the list of known
issues/TODOs. If you discover any problems, please send an e-mail to
bug-easejs@gnu.org.
@ -11,14 +34,14 @@ information and a plethora of examples until the documentation is
complete.
* TODO Trait Extending
** TODO Trait Extending
Traits are able to "extend" classes, thereby declaring interface
compatability; this is a useful alternative to interfaces when a trait is
designed to augment a specific type. This convenience should be extended
to traits: a trait should be able to "extend" another trait in the same
manner that it may extend a class.
* TODO Documentation
** TODO Documentation
Due to the trait implementation taking longer than expected to
complete, and the importance of the first GNU release, trait
documentation is not yet complete. Instead, traits have been
@ -28,18 +51,18 @@ complete.
Comprehensive documentation, including implementation details and
rationale, will be available shortly.
* TODO Static members
** TODO Static members
Static members are currently unsupported. There is no particular
difficulty in implementing them---the author didn't want it to hold
up an initial release (the first GNU release) even further.
* TODO Getters/setters
** TODO Getters/setters
Getters and setters, although they act like properties, should be
treated as though they are methods. Further, they do not suffer
from the same complications as properties, because they are only
available in an ES5 environment (as an ECMAScript language feature).
* TODO Mixin Caching
** TODO Mixin Caching
The pattern =Type.use(...)(...)=---that is, mix a trait into a class
and immediate instantiate the result---is a common idiom that can
often be better for self-documentation than storing the resulting
@ -51,7 +74,7 @@ complete.
fairly cheap to use such an idiom. Further, this would permit the
Scala-like ability to use Type.use in Class.isA checks.
* TODO Public/Protected Property Support
** TODO Public/Protected Property Support
Private properties are currently supported on traits because they do
not affect the API of the type they are mixed into. However, due to
limitations of pre-ES5 environments, implementing public and
@ -63,14 +86,14 @@ complete.
encapsulate all data, not expose it---but it does have its
legitimate uses. As such, this is not a high-priority item.
* TODO Trait-specific error messages
** TODO Trait-specific error messages
All error messages resulting from traits should refer to the trait
by name and any problem members by name, and should offer
context-specific suggestions for resolution. Currently, the errors
may be more general and may reflect the internal construction of
traits, which will be rather confusing to users.
* TODO Performance enhancements
** TODO Performance enhancements
The current trait implementation works well, but is relatively slow
(compared to how performant it could be). While this is sufficient
for most users' uses, there is plenty of room for