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

["Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLEREZZA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062050#comment-13062050 ] 

Reto Bachmann-Gmür commented on CLEREZZA-596:
---------------------------------------------

+1 for having such a tiny and well documented issue, as you did commit to trunk I hope closure will happen very soon. (As for the actual content I disagree, I think "separation of concern" is a plus rather than reducing the number of classes and I don't think builders are a bad thing especially when the it reduces the number of class types in the vm allowing for better optimizations by the vm - but as a whole I consider the change as rather unimportant so I focus on stuff I consider more important (for the relase and in general)).

> 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