[The Demystification of Lasso Custom Types] at tagSwap.net: Open Source Lasso Code

[The Demystification of Lasso Custom Types]

: Encapsulation

This is an Object Oriented Programming term. It means that data and code which manipulates that data are contained within a single programming unit. In Lasso, that single unit is the custom type. The intent is that the data in the ctype cannot be acted upon except through the code that is in the ctype. If that is the case, then anything that causes errors in that encapsulated data must be caused by the encapsulated code. This keeps code which alters the data on a very short leash. It's easier to track and debug; and, once it is debugged, it should be perfectly reliable every time it is implemented.

Greg Willits, October 02, 2006

Due to its length, I have opted to publish this article as a PDF which can be downloaded from the link below. However, to tickle your curiosity, the following are some excerpts.

You've probably heard of Lasso's custom types and thought they were for advanced developers doing tricky things that you'd never be interested in. In this article, my goal is to dissolve your fears, and to help you see how simple custom types are, and how to use them to improve the readability, reliability, and maintainability of your code.

It's true that custom types can do tricky things, and that custom types are the basis for doing complex object-oriented programming. However, it is also true that custom types do not require that you be doing tricky things to take advantage of them, and you do not have to be an OOP guru to understand them.

What is a Custom Type?

A custom data type is nothing more than regular Lasso code structured in such a way that you can store multiple data chunks in a single variable, and perform custom actions on those data chunks using the Lasso member tag syntax.

A standard lasso variable can hold data (even multiple chunks of data using arrays and maps), but there's only a few preset actions that can be performed on that data. For example, if we had an array of purchase order line item SKUs, there is, of course, no member tag to check the in-stock status of each item in that array. To do that, we have to write some custom code that iterates through that array and does whatever is necessary such as look for each item in an inventory database table. So, arrays are neat, but they're very simple.

A custom tag can perform specialized actions, but it cannot hold data. We could write a custom tag to do our database searches above, but the tag cannot store the results. It executes its code, then everything disappears. We'd have to create another array to store the results of each SKU search, or reformat our original array into an array of pairs or maps. In this example, we might have up to three separate parts to our solution: the original array, a custom tag designed to search for stock status of a provided SKU, and a results array.

A custom type allows us to combine all those pieces into a single entity which uses the same $variable->memberTag syntax of native lasso data types (strings, arrays, maps, etc). Just like we might have a string variable on which we find the size using $x->size, or remove a prefix using $x->(removeleading:'pre-'), we can use custom types to have something that ends up looking like $myPurchaseOrder->(getStatus:-sku='xyz') to perform custom actions and $myPurchaseOrder->'shipDate' to retrieve a specific piece of data. Ultimately, how we code with a custom type is just like any other Lasso variable and member tag combination.

Why Use Custom Types?

There are many reasons to structure code into things like Lasso's custom types. The one I explore the most in the article is encapsulation. For most moderate Lasso projects, the benefits of encapsulation are mostly code readability, reliability, and maintainability. As projects get larger or have multiple developers at either the same time or over time, the benefits become more significant.

For small sites with a dozen pages of unique functionality that don't change much over time, there may be little incentive to restructuring the code into custom types. However, for developers frequently building new applications, or captive developers expanding their online application features, custom types provide a significant advantage in realizing the promise of reusable code and programming productivity.

Update: Aug 2, 2005: Capturing Params in onCreate

On Page 7, I provided an example of populating instance vars with params. Lasso has typically not supported using the self-> tag with a substitution for the target, and at one point I was told it'd never happen, but yeeha and yippy skippy, indeed in LP8 it is possible. So, if you use named params when declaring a ctype, you can use code like the following to populate your instance vars (which have to have the same name as the param names).

define_tag:'onCreate';
    local:'pName' = string;
    iterate: params, local:'thisParam';
       #pName = (#thisParam->first);
       #pName->removeleading:'-';
       if: #thisParam->type == 'pair';
          self->#pName = (#thisParam->second);
       else;
          self->#pName = true;
       /if;
    /iterate;
 /define_tag;

Update: Oct 1, 2006:

A few refinements to the text and code samples, addition of some guidelines for naming objects, instance vars, and member tags. A little discussion on polymorphism. More details of onCreate differences in LP 5 through 8.

Files

Demystification of Lasso Custom Types