[jira] [Closed] (CLEREZZA-597) no need for EzLiteral.lang(l: Symbol)

["Henry Story (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CLEREZZA-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henry Story closed CLEREZZA-597.
--------------------------------


> no need for EzLiteral.lang(l: Symbol) 
> --------------------------------------
>
>                 Key: CLEREZZA-597
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-597
>             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 enumerations  
> 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 needed

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira