|
2 | 2 |
|
3 | 3 | The Grease Portability Library [](https://travis-ci.org/SeasideSt/Grease) |
4 | 4 | ====== |
5 | | -Grease enhances the ANSI Smalltalk standard. With only a few exceptions, we assume platforms are fully ANSI-compliant. Platforms want to support Seaside and standardization makes this easier for the project’s developers and its porters. |
| 5 | + |
| 6 | +The main repository of Grease is on Smalltalkhub: (http://www.smalltalkhub.com/#!/~Seaside/Grease11). This repository mirrors it. |
| 7 | + |
| 8 | +Grease enhances the ANSI Smalltalk standard. With only a few exceptions, we assume platforms are fully ANSI-compliant. Platforms want to support Seaside and standardization makes this easier for the projectâs developers and its porters. |
6 | 9 |
|
7 | 10 | Grease defines expected APIs with unit tests. Platforms can quickly determine if they are compatible and users can examine the tests to determine exactly which behaviours they can count on. |
8 | 11 |
|
9 | | -Grease takes a pragmatic approach to compatibility. Sometimes a method behaves so differently on two platforms, for example, that we are forced to avoid it or to standardize on a new selector. To get standard exception signaling on all platforms, Grease is forced to provide special exception classes that can be subclassed. Sometimes we need to put “right” aside and settle, instead, on a solution that can be implemented everywhere. |
| 12 | +Grease takes a pragmatic approach to compatibility. Sometimes a method behaves so differently on two platforms, for example, that we are forced to avoid it or to standardize on a new selector. To get standard exception signaling on all platforms, Grease is forced to provide special exception classes that can be subclassed. Sometimes we need to put ârightâ aside and settle, instead, on a solution that can be implemented everywhere. |
10 | 13 |
|
11 | | -Grease tries to be concise and consistent. Despite its pragmatic approach, we still want to be “right” as much as possible. Because it’s hard to remove functionality once it has been added, we need to carefully consider each addition before proceeding. We’re moving slowly and looking for methods that are commonly used and that have clear names and semantics. |
| 14 | +Grease tries to be concise and consistent. Despite its pragmatic approach, we still want to be ârightâ as much as possible. Because itâs hard to remove functionality once it has been added, we need to carefully consider each addition before proceeding. Weâre moving slowly and looking for methods that are commonly used and that have clear names and semantics. |
12 | 15 |
|
13 | | -Grease does not try to solve all problems. We are not testing Sockets or HTTP clients. We don’t expect platforms to have standard SSL or graphics libraries. Its scope may grow over time, but for now we’re focusing on extending the functionality of the core classes defined in the ANSI standard (collections, exceptions, streams, blocks, etc.) and on other pieces of functionality that are critical to the Seaside project (e.g. random number generation and secure hashing). |
| 16 | +Grease does not try to solve all problems. We are not testing Sockets or HTTP clients. We donât expect platforms to have standard SSL or graphics libraries. Its scope may grow over time, but for now weâre focusing on extending the functionality of the core classes defined in the ANSI standard (collections, exceptions, streams, blocks, etc.) and on other pieces of functionality that are critical to the Seaside project (e.g. random number generation and secure hashing). |
14 | 17 |
|
15 | 18 | Grease is widely adopted. Implementations exist already for all platforms that support Seaside 3.x. As well as Seaside, new versions of Magritte, Pier, and Monticello are already being implemented on top of Grease. |
16 | 19 |
|
|
0 commit comments