Am 17.09.2009 um 08:26 schrieb Lachlan Deck:
> On 17/09/2009, at 3:46 PM, Q wrote:
>
>> On 17/09/2009, at 3:01 PM, Lachlan Deck wrote:
>>
>>>> So you don't have to have sleepless nights over deadlocks when
>>>> using concurrent request handling :)
>>>
>>> unless, I imagine, the libraries you primarily depend on are
>>> themselves not written in scala(?)
>>>
>>>> Now, developing and deploying more ambitious Web 2.0 UI is a
>>>> possibility...
>>>
>>> I am interested in Groovy in particular, Quinton, as it does have
>>> reasonably decent tool support nowadays. (It appears that Scala
>>> does too: http://www.scala-lang.org/node/94)
>>
>> I need to have another look at groovy, and how far its eclipse
>> support has come since the last time I tried it.
>
> Okay. Let me know either way.
>
>>> So... I'm happy to look into updating the new Component/View
>>> wizard for wolips to creating the component class in alternate
>>> languages (if desired) as that seems to me to be the primary
>>> obstacle to utilising these two languages with WOLips (is that
>>> what you meant Quinton?).
>>
>> The lack of support in the wizards is more an inconvenience, than
>> an obstacle that would prevent you using scala or groovy.
>
> Sure - though it would be a hassle.
>
>> I wouldn't be in a rush to support such things in wolips unless you
>> are actually using them yourself ongoing, else they will likely
>> wither on the vine.
>
> Certainly. I'd like to see what using groovy would be like for
> things like components. I'm not clear on whether wogroovy is needed
> or not and what the wolips groovy plugin actually does ?
The wolips groovy plugin does some tricky stuff to enable real rad.
Real rad means: Add / remove variables and methods at runtime.
I've made a video several years ago: http://wiki.objectstyle.org/confluence/download/attachments/2097273/groovy.mov
Unfortunately it requires a patched wo version.
>
>> The real issue is whether WOLips' component integration and binding
>> validation would still work effectively or not. I suspect with
>> scala it probably will to a point, but with groovy it would depend
>> on what ended up in the bytecode. Generic type parameter resolution
>> will only work with java because WOLips introspects the source code
>> using JDT.
>
> Certainly an important consideration.
Uli
This archive was generated by hypermail 2.0.0 : Thu Sep 17 2009 - 02:55:59 EDT