Mailing-List: contact clerezza-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: clerezza-dev@incubator.apache.org
Date: Thu, 7 Jul 2011 22:14:16 +0000 (UTC)
From: "Henry Story (JIRA)" <jira@apache.org>
To: clerezza-dev@incubator.apache.org
Message-ID: 
 <894731062.9356.1310076856902.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (CLEREZZA-596) Replace LiteralBuilder with
 EzLiteral
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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 LiteralBuilder(val lexicalForm: 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