Please comment:

Which would you prefer?

1. quick 1.0 release with potentially incomplete APIs
2. longer 1.0 release with more complete APIs and more experience before "1.0 lock down"

If we want a quick 1.0 release then we need to prioritize features. The list of features which I think are required for a usable 1.0 beyond what we have now:

1. Finish sys APIs (regex, process)
2. Finish web APIs (add client side APIs, HTTP 1.1 chunking)
3. Finish fwt APIs
4. Add XML APIs (with basic pull/DOM support, namespaces, maybe XPath)

What features do you consider required for a 1.0 release?

1. Quick release.
2. Finish sys APIs
3. Finish fwt APIs

Depends on what 1.0 signifies really - although personally I think it may be a good time to freeze any language-level changes (and release that as 1.0) then tweaks the libraries as we go along. Java does pretty much that, apart from assert, @interface, <T>, got dragged to one side and shot in the head

However, judging by the still heated debates on language features I guess many might not think Fan should freeze this soon...

I think we are working through a lot of ideas at quite a quick pace, but we will have to take decisions on them too.

Language wise, I find the following areas to be weak:

• Namespacing of pods. I don't believe comAcmeFooPerson works as a pod name. Maven has already demonstrated that file systems can't cope with lots of names in the same folder, and had to switch to dot separated format that will map to folders. This doesn't have to be changed for 1.0, but it will eventually have to be changed for practical reasons.
• Namespacing of facets. I find facets as simple strings to be incredibly open to abuse. There will be name clashes, its inevitable. Types are eventually going to be needed.
• Immutable setter. Whether by an obj.dup or a new operator, we need a specific mechanism. Fan needs a few "sales" features, and excellent immutable support is one.
• Duration literals. Something broader is needed. Duration literals just feel very specific to be at the language level.
• Object construction. We've talked a lot, but not managed to agree on a complete solution. I don't believe that 1.0 is acceptable whilst the object construction process is not fully defined. This links into with-blocks and non-local returns. I think unified-with-blocks may yet win me round.
• Not null support. I want to define variables as not allowing null. I understand the risks of overdoing this, and I don't want to go there. But, nulls really are the bane of our lives, and the null operators are only part of the solution.
• equals() and compareTo() should be retricted to taking a parameter of the correct type. This has annoyed me often enough to be worth solving.
• Resource allocation. Being able to close a resource after its finished with, which may just be an API based solution.
• Well defined serialization and deserialisation. I'd like to use the same mechanism for JSON output, or XML output or to handle cycles.
• Native ingegration (Java/.Net).

In addition, I've asked for:

• Wrapper/derived types. I believe that these would be a stand out feature, allowing deeper levels of understanding about the code we write in enterprises. (Ignore the units discussion, focus on the Username is convertible to Str example - these are essentially enums on steroids).

I also think that there hasn't yet been that much examination of libraries, because there hasn't been much code written other than by Brian/Andy.

For example (and with respect), I think the DateTime API, while understandable, really shouldn't be the one API that gets baked into the sys pod and used by everyone as is. There is a danger of repeating the mistakes of java.util.Date here. Dates are probably complex enough to have their own pod.

And finally, with my cheeky face on, I'd humbly suggest that end-of-line braces will be a lot more popular to Java/C# developers than start-of-line. But heh, not everything in Fan can be good ;-)

(I'm sure I've forgotten something)

Oh, and your question? I'd like to see answers to each of the above. If the choice is made to do nothing, then this needs to be documented outside the forum (wiki/"design choices" page). So, I'd say web and fwt APIs are less important. Sys and XML APIs are more important.

BTW, http://steve-yegge.blogspot.com/2007/02/next-big-language.html is an essential list to be considered, even if not all the items Fan will choose to adopt.

Really not worth derailing the interesting discussion for, just a small finger in the air pointing out that all the C# projects I've seen use Allman/BSD style. A poll I suggested to java.net out of curiosity revealed that 20% use this even in the Java world, while 60% use K&R/SUN style:

http://today.java.net/pub/pq/210

...and many do so mostly to comply with SUN's ancient guidelines from back when we had small CRT's. Last but not least, MSDN examples suggests de-facto C# style indeed beeing Allman/BSD.

I don't see the need to rush, my vote would be for a longer more complete release. My order would be

1. Language features
2. Sys
3. fwt
4. web
5. xml

By language issues, I mean similar thing to what jodastephen mentioned above. Object construction, with blocks, serialization.

I'm also curious what folks think about adding more meta programming capabilities to Fan.

Namespacing of pods. I don't believe comAcmeFooPerson works as a pod name.

Well if I thought it wouldn't work, I would have designed it that way :) It is hard to imagine even big projects having more than 100s of pods - that would probably be pushing into multiple million lines programs (which in Fan would be huge). And even embedded file systems and managers handle 100s of file just fine (you have to get into several 1000 before problems crop up). If we need further discussion, let's open a new topic.

Namespacing of facets.

Open issue, my last thoughts. No one has responded. I am pretty open to a solution on this issue, but I'm not currently giving it any thought myself.

Immutable setter. Whether by an obj.dup or a new operator, we need a specific mechanism

Object construction.

Same issue really. I agree this is a hole. Strangely enough it hasn't been an issue in any of the code I've developed, so I don't consider it a show stopper. Although it definitely deserves yet more attention.

Not null support.

I am extremely skeptical of such a feature - especially if the desire is to explicitly force me to handle any potentially null value. And I don't think it suits Fan's laissez-faire type system. Although I can see the desire because I've toyed with the feature myself, so I'd welcome talking about it.

equals() and compareTo() should be retricted

It annoys me too, and I kept on my todo list for a long time. I would welcome proposals which don't introduce contra-variance. But I gave it lots of thought and gave up.

Resource allocation. Being able to close a resource after its finished with, which may just be an API based solution.

As I've stated before, it we don't get unified-with blocks (which seems unlikely), then I will add the C# styled using statement.

JSON output, or XML output or to handle cycles

I definitely agree with XML and JSON (although I only think XML is required for 1.0). I'm opposed to cycle handling, but if people really want that, let's open a new thread.

I think the DateTime API, while understandable, really shouldn't be the one API that gets baked into the sys pod and used by everyone as is.

I don't think we can live without a sys level date API - that is about as fundamental as strings. The API isn't quite finished, however I expect when complete it should solve 99% of what people need. However that doesn't preclude more specialized additional pods. For example I'd love to have a iCal pod which handles complicated rrules and stuff like that.

To re-iterate what I'd like to glean from this thread are two things. What features should be prioritized - we've had some great feedback on that topic.

But more importantly I'm trying to understand how much we should rush a 1.0 release. What I'm most interested in are the requirements of people who want to start real projects with Fan. If you are considering a real project then please let me know (you can email too).

If you are considering a real project then please let me know

I am planning to start again after numerous frustrated attempts implementing stuff like this, this and this

The primary issue with implementing (and expressing) such extensive structures in Java is - you guess it - the verbosity of the language. I find Generics to be a big plus, yet no mixin, no This, no once etc. means that I have to create so many more classes and methods and I quickly run out of steam. I mean, if I start to find tedious myself, how would I expect anyone else to implement on top of the framework?

As far as Fan goes other features seem to be plugging the right holes for the absense of generics. Immutability through const is also very nice, and I look forward to comparing the parallelism achievable on Fan.

Worries for me at the moment includes lack of concurrency in Fan's library, e.g. ConcurrentSkipListMap and ExecutorService under java.util.concurrent.