Implementing Laziness

http://matt.might.net/articles/implementing-laziness/

For this week’s blog I will be taking a look at an article on matt.might.net called ‘Understand and Implement Laziness with examples in Scala, JavaScript, Swift and Racket’. Within this article, Professor Might explains the concept of ‘laziness’ in programming. Laziness (other than the laziness we all initially think of) means delaying the computation of a value until the value is necessary. There are two interpretations of laziness, by-name and by-need. Using the by-name interpretation, the computation of the value is delayed until necessary and the computation is repeated each time it is used. Compared to by-need interpretation in which the computation of the value is delayed until necessary, and then the result is cached for subsequent users. The article explains how most languages we use today are strict languages, meaning they compute the value of an expression immediately. While other languages such as Haskell and Scala are lazy or can be called lazy if explicitly specified for a given situation of variables or parameters.

Scala, which is strict by default, can use the lazy keyword if explicitly specified. Therefore, it makes it easy to use as an example.

val x = { print (“foo”) ; 10 }

print (“bar”)

print (x)

As the article explains, this will print foo, then bar, then 10. But if we use the lazy keyword, we see that the output changes.

lazy val x = { print (“foo”) ; 10 }

print (“bar”)

print (x)

This will produce the result bar, then foo, then 10. The use of the lazy keyword delays the computation of x until it is actually needed.

Parameters can also be lazy. Some languages allow the definition of explicitly lazy parameters to functions. The parameters are not evaluated until they are used. In lazy languages like Haskell, the parameters are all implicitly by-need.

The use of lazy parameters and variables allow the programmer to save on computing space and loading time by holding off on the creation of complex objects and variables until needed.

Advertisements

Service Locator Pattern

For this week’s blog article, I will be looking at the Service Locator Pattern. The article explains how the Service Locator Pattern is a relatively old pattern that was originally used to improve the modularity of an application by removing the dependency between the client and the implementation of an interface. There are many principles that enable you to implement maintainable applications: the Open/Closed Principle, the Liskov Substitution Principle, the Interface Segregation Principle, and the Dependency Inversion Principle. Although these principles are all helpful, they all share the same issue. You need to provide an implementation of the interface, and if that’s done by the same class that uses the interface, you have a dependency between the client and the implementation.

The Service Locator Pattern avoids this dependency altogether. The service locator pattern acts as a central singleton registry that provides implementations of different interfaces. The component that uses the interface no longer needs to know the class that implements the interface, and instead of instantiating the class, it gets an implementation from the service locator. You can implement the service locator as a static service locator that uses a field for each service to store an object reference. Or you can create a dynamic service locator that keeps a java.util.Map with all service references.

Although the Service Locator Pattern can be helpful there are concerns against it and it is also largely outdated by the Dependency Injection pattern. The three most common concerns against the Service Locator Pattern are that all components need to have a reference to the service locator, which is a singleton, the service locator makes the application hard to test, and a service locator makes it easier to introduce changes in interface implementations.

The service locator pattern is just one of the many different patterns that you can use to decouple a client from the implementation of an interface. The pattern uses a singleton registry that provides an instance of a service interface. This helps to move the dependency to the interface implementations from the client of the interface to the service locator class. Although the pattern has some downfalls and is slightly outdated, it can still be used in certain situations.

Introductory Blog

Hello!

My name is Jarrett Stone and this is my computer science blog. Throughout the semester, I will be staying informed in the ever changing computer science field through various media such as news outlets, podcasts, and other blogs. On the subjects I find interesting or important to the field, I will write my own opinions on in this blog.

Currently, I am a Senior at Worcester State University with a major in Computer Science and a concentration in Big Data Analytics. I have also worked an internship at Infineon Technologies for the past 9 months in Leominster, Massachusetts. As a Big Data Analytics concentration, I hope to find current news on this specific area and how it changes our world today and how it will change the world in the future.

 

Good company in a journey makes the way seem shorter. — Izaak Walton