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 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.
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Thu Sep 17 2009 - 02:27:59 EDT