RFCs

Extension methods implementation revamped

Just shortly after announcing the removal of the original extension methods implementation we have now come up with a faster, less-clumsy and well-behaving extension method implementation - and have reactivated the corresponding RFC, scheduled for implementation in SVN next week.

RFC #0093: xml.meta

Scope of Change
The xml.meta API will be extended to include a way to marshal objects to trees instead of only to strings, and unmarshal XML from streams.

Rationale

• Performance improvement over Tree::fromString(Marshaller::marshal())
• Use the tree / node objects for further modification
• Performance improvement over Unmarshaller::unmarshal(Streams::readAll())

RFC #0203: Unbuffered queries

Scope of Change
Unbuffered queries will be supported by a dedicated API. Instead of using rdbms.DBConnection::query() (or any of the insert, update, delete or select methods), the result-only rdbms.DBConnection::open() method will support unbuffered queries.

Rationale
Incremental row processing to save memory.

Read the full RFC here

RFC #0201: XP Overlays

Scope of Change
Path files will support prepending elements to the class path via special syntax.

Rationale
Sometimes it's necessary to overwrite certain parts of the XP framework's classes (the ones distributed in xp-rt xar files). One of the usecases is to keep using deprecated APIs in conjunction with a release in which they were removed, but being able to use new APIs provided with this release in other parts of the program. Another example is the ability to production- test new functionality (e.g., from SVN head, or even from the experiments in xp forge) together with the latest release.

Read the full RFC here

RFC #0200: XML API Rework

Scope of Change
The XML API will be extended to fully support markup-style XML documents.

Rationale
At the moment, certain information will be lost when loading and then emitting an XML tree:

Read the full RFC here

RFC #0197: Type literals in tokens

Scope of Change
A common way to denote type literals in generated sourcecode will be introduced.

Rationale
An example of where this is used is the type dispatching methods described in RFC #0195. Another example is generics generation, as described in RFC #0193.

Read the full RFC here

RFC #0193: Generics optimization

Scope of Change
Generics will be optimized.

Rationale

• Improve performance
• Enable reflection for generics
• Enable reflective creation of generics
• Support primitives a generic arguments

RFC #0175: New io.zip package

Scope of Change
A new package named io.zip will be created.

Rationale
Reading and creating zipfiles.

Read the full RFC here

RFC #0196: I/O Collections random access

Scope of Change
There will be methods in the io.collections interfaces that will allow creating, finding, and removing children.

Rationale
Extend the I/O collections classes from read-only to include a full-featured filesystem access API.

Read the full RFC here

Generics in C#, Java, and C++

In this interview from quite a while ago Bruce Eckel and Bill Venners talk with Anders Hejlsberg about generics implementations in C# and Java - the differences in their implementations, type erasure vs. runtime instantiation, reflection and how they compare to C++'s template mechanism. This has inspired us to come up with RFC #0193 - and moving our generics implementation closer to the one in the CLR.

Subscribe

You can subscribe to the XP framework's news by using RSS syndication.

Categories