incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henry Story (JIRA)" <>
Subject [jira] [Resolved] (CLEREZZA-597) no need for EzLiteral.lang(l: Symbol)
Date Fri, 08 Jul 2011 13:04:17 GMT


Henry Story resolved CLEREZZA-597.

    Resolution: Fixed

> no need for EzLiteral.lang(l: Symbol) 
> --------------------------------------
>                 Key: CLEREZZA-597
>                 URL:
>             Project: Clerezza
>          Issue Type: Improvement
>            Reporter: Henry Story
> EzLiteral has 3 lang methods. 
> class EzLiteral { ...
> 	def lang(lng: String): PlainLiteral = lang(new Language(lng))
> 	def lang(lng: Language) = new PlainLiteralImpl(string, lng)
> 	def lang(lng: Symbol) = lang(new Language(lng.toString()))
> ...}
> It would be best to have only the second Language one as one can then write very nicely
>   "this is some text" lang en
> (if one has Language constants)
>   The second method, shown below, seems that natural one while the a good list of language
> does not exist. It requires to add two quotation marks.
>  "this is some text" lang "en"
> But the third option of using 
>  "this is some text" lang 'en 
> just seems to be going a bit too far in optimisation at the cost of a method.  
> So currently each one has its pros:
> Language("en") it could both be the easiest to write, can be type safe, and in any case
is needed since Language objects are used in the API
> String: is not type safe, but quite common, and needed to create the Language object
> Symbol: is not type safe, not common, save one character to type, but requires one extra
method, and one more indirection
> Anyway, three ways to get a language is too much at present. I can be added later if

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message