incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henry Story (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLEREZZA-596) Replace LiteralBuilder with EzLiteral
Date Fri, 08 Jul 2011 17:40:16 GMT

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

Henry Story commented on CLEREZZA-596:
--------------------------------------

So your issue would have been (had you not had other more important issues to deal with) that
by creating a subclass of Literal named EzLiteral, this creates one more class in the VM?
How is this a problem as opposed to it having previously created a UriRefBuilder and a LiteralBuilder?
There you had two classes in the VM. So it's a reduction of 50%. 

 As for separation of concerns, I don't see how that applies here, since what is being done
is exactly what is being done in RDF: A function is applied on a string to produce a different
typed literal. You'd have to find a concern that suffered from not being separated for your
case to have some weight. I good example would have been useful. Perhaps one day when you
have more time.



> 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

        

Mime
View raw message