[jira] [Resolved] (CLEREZZA-596) Replace LiteralBuilder with EzLiteral

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

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

Henry Story resolved CLEREZZA-596.
----------------------------------

    Resolution: Fixed

> Replace LiteralBuilder with EzLiteral
> -------------------------------------
>
>                 Key: CLEREZZA-596
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-596
>             Project: Clerezza
>          Issue Type: Improvement
>            Reporter: Henry Story
>
> In package org.apache.clerezza.rdf.scala.utils  the following classes are defined
> 	class LiteralBuilder(val lexicalForm: String) {
> 	        def lang(lang: String) = new PlainLiteralImpl(lexicalForm, new Language(lang))
> 		def ^^(dataType: UriRef) = new TypedLiteralImpl(lexicalForm, dataType)
> 	}
> 	class UriRefBuilder(val string: String) {
>                 def uri = new UriRef(string)
>         }
> This then also comes with the following implicit  transformations
> 	implicit def string2litBuilder(str: String) = new TcIndependentConversions.LiteralBuilder(str)
> 	implicit def string2uriRefBuilder(str: String) = new TcIndependentConversions.UriRefBuilder(str)
> 	implicit def string2lit(str: String) = litFactory.createTypedLiteral(str)
> I propose reducing the classes needed down to one and one implicit.
>      implicit def string2lit(str: String) = new EzLiteral(str)
>      class EzLiteral(lexicalForm: String) extends TypedLiteralImpl(lexicalForm,XSD.string) {
> 	       def lang(lang: String) = new PlainLiteralImpl(lexicalForm, new Language(lang))
> 	       def ^^(typ: UriRef) = new TypedLiteralImpl(lexicalForm, typ)
> 	       def uri = new UriRef(lexicalForm)
>       }
> Advantages:
>  + halving of number of classes 
>  + 3 times fewer implicits:
>       implicits should be avoided. They are particularly useful when one needs to add methods to code one does not control. But adding them indiscriminately makes code look magical, and then could be difficult to debug. When one controls the classes one should make methods (functions) explicit.
> + functional: the concept of a Builder is very much a concept of OO programming for objects that have changing state. But here there is no changing state: the objects are immutable already. Functional programming works with methods that take an immutable object and return another immutable object. Here we go from a function on a string to a some other thing: other types of literals. see CLEREZZA-595 for details on how literals can be thought of as functions from strings to abstract objects.

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