One thing about fan (and about scala, incidentally) that bugs me to no end is the insistence of being both JVM and .NET compatible.
Why????? Because of this, Fan (and scala) have to re-invent everything, every library that ships with java / .net. Can't have ArrayLists just like java does, because then .NET gets the shaft. Can't have them like .NET, because then java people feel out of whack. So fan must have its own take on it. So on and so forth. Annoying. If you must, then make two versions of the language with entirely different libraries. The amount of people that care about seamless cross-compiling to both .NET and JVM are very very very small and its not worth the massive cost. Other than that, sure, fan is interesting. Its lack of support for true non-null-ness annoys me, though. It really isn't so hard to get right if you already have generics, and in my books, generics are a must have. Preferably reified. Probably a smidgen too late to whine about all that now, though. On Dec 22, 3:00 pm, Brian Frank <[email protected]> wrote: > Interesting discussion on Fan! > > Regarding generics - clearly that is a tradeoff towards the dynamic > end of the spectrum. As James points out there are lots of container > types which might benefit from generics - in Fan these would be > written in the pre-1.5 style using just Obj. However Fan does most > casting implicitly so your code would look a lot cleaner. > > But one of the interesting things I've found is that designing public > APIs between modules before generics never posed a really a big issue > for me, because most APIs that exposed a collection could do as an > array (which is how most of the original Java APIs worked). It is > kind of the same philosophy in Fan - because a public API can expose a > parametrized List, Map, or Func it is pretty easy to design public > APIs that are mostly statically typed. It is just the stuff internal > to a module where you use a more dynamic programming style. But in > the end it really just a matter of engineering trade-offs and personal > preference. > > Some of the comments regarding fields: > > > It is also important that a subclass can intercept and override a property > > Property managed by DI container (WebBeans) for state isolation; > > This is something I've always done in previous frameworks. We don't > have it in Fan yet (other than the normal override the setter), but it > is something we want to do. We'll probably do it via something like > pluggable Python style decorator functions which are called on field > sets (we haven't designed that feature yet). > > > Immutable property with lazy init and no synchronize; > > You can declare a method with the once keyword which executes its once > and caches the result on future calls (like Eiffel). Although there > is no shared mutable state between threads so synchronization doesn't > really come into play. > > > My biggest problem with Java is how it's not possible to reference a > > property. > > Fan is really focused on meta-programming. As such there is a lot of > reflective capabilities built-in. In this case slot (method/field) > literals are part of the syntax: DateTime#year which is effectively > the same as looking up a method by name (this sort of stuff is way > easier when you don't have methods overloaded by parameter type). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
