Featured in AI, ML & Data Engineering

In this article, author shows how to use big data query and processing language U-SQL on Azure Data Lake Analytics platform. U-SQL combines the concepts and constructs both of SQL and C#. It combines the simplicity and declarative nature of SQL with the programmatic power of C# including rich types and expressions.

Featured in Culture & Methods

The book Agile Leadership in Practice - Applying Management 3.0 by Dominik Maximini is an experience report of the agile transformation journey of NovaTec. Maximini shares his experiences from applying principles and practices from Management 3.0, success stories, failure stories, and learnings from experiments.

Featured in DevOps

Yuri Shkuro presents a methodology that uses data mining to learn the typical behavior of the system from massive amounts of distributed traces, compares it with pathological behavior during outages, and uses complexity reduction and intuitive visualizations to guide the user towards actionable insights about the root cause of the outages.

This is aimed to allow for lazily initialized attributes of a class. In this case, the @content instance variable is initialized with [] when it's accessor method content is called, unless it has already been initialized. The ||= operator means "if the left hand variable is nil, set it to the right hand value, otherwise just return the left hand variable's value".

However, as Piers points out, there is a problem with certain values due to the way Ruby treats boolean values and nil. Here an example to illustrate:

a = falsea ||= "Ruby"

What's the result of this? Since a was initialized in the first line, the second line should not have had any effect. However, executing that code reveals that a now has the value "Ruby", instead of false.

The problem becomes clear by remembering the common way to write nil checks in Ruby:

if name puts name.capitalizeend

In Ruby, a nil is interpreted as boolean false, so the code in the if clause will only run if the name is not nil.

While this is usually not a problem, in the lazily initialized attributes code, it's a problem if a legal value for attribute is either nil or false. In that case, an access would reset the variable to it's default value.

This is certainly a corner case, however it's the kind of issue that can cause long debugging sessions, trying to figure out why some attributes are occasionally reset while others aren't.

This only initializes the variable if the variable hasn't been defined yet.

This little example could be blamed on Ruby and some of it's language features - but it's widely known which type of workers blame their tools instead of themselves. While the conciseness of Ruby is very helpful, there are cases where more explicit expression of intent is safer. In this case, the ||= wasn't the right solution and instead the initialization code is supposed to check if the variable had been defined yet.

Have you been bitten by issues such as this one? Are there Ruby features you like to avoid to prevent subtle errors?

More Variable Metadata

Your message is awaiting moderation. Thank you for participating in the discussion.

I've often thought we need more metadata on our variables (or function arguments, or properties, etc). Currently we have just one: null. A reference can either be null, or have a value. I'd like to also have "defined" to say if a given name has been defined. "Initialized" can say if it has ever been set before, in which case the value could also be nil or non-nil. Also "null" can work just like it does now (or nil in Ruby, whatever). A hybrid "has value" concept would be nice too, which requires both "initialized" to be true and also "is null" to be false. With these constructs it would be possible to write very clear expressions such as "if x is initialized ..."

definitely a corner case.

Your message is awaiting moderation. Thank you for participating in the discussion.

def content @content ||= []end

In what case could something return an array or false- n valued logic? Seems completely off base as a criticism.100% of the time I use code like this it's to avoid doing nil? checks all over the code. If you are writing code where nil is an acceptable value, why would you need to initialize the array to empty? It seems odd to have a semantic difference between nil and empty array where nil is something that the array explicitly gets set to after it is initialized. A programmer would generally expect that nil means uninitialized. Now I have to check for nil every time I call:

content.each

In the case where you are actually dealing with a boolean, you don't have to do anything- the nil naturally works in conditional expressions.

Maybe I just need a better example to understand this particular point. I agree with the general thrust of the article- that sometimes being concise can obscure the meaning of the code, but I don't see this idiom as problematic. On the other hand- having 0 != false in Ruby is a bit weird, no pun intended.

Re: definitely a corner case.

Your message is awaiting moderation. Thank you for participating in the discussion.

The original article on "Lazily Initialized Attributes" ( blog.jayfields.com/2007/07/ruby-lazily-initiali... ) where this issue was found, shows a general way to initialize attributes only when they're actually accessed. So, this is not specific to lists, but generally to using this idiom for initializing attributes.

So, if you use this idiom to create a boolean attribute or an attribute that can be some value OR nil, then you can run into trouble. Eg

class Foo def red? @red ||= true end def red=(arg) @red = arg endend

x = Foo.newx.red? # returns true, default value

x.red = false # @red is now false

x.red? # returns ... true, because of the issue described in the article

Re: definitely a corner case.

Your message is awaiting moderation. Thank you for participating in the discussion.

The trickiness in Jay's case is trying to lazy initialize a boolean to true. That's the only place one could actually run into a problem, but a simple nil check would work there. I still think the standard

@x ||= default

works except for cases where you want to initialize a boolean.

In any case, lazy initialization should probably only used for expensive operations, not for setting simple defaults.

Re: More Variable Metadata

Your message is awaiting moderation. Thank you for participating in the discussion.

I think the distinction between nil? and empty? or blank? (a Rails addition) is more interesting area to explore. I think using or implementing those methods makes things more clear than setting something to nil and expecting that to mean empty, as opposed to uninitialized.

Re: definitely a corner case.

Your message is awaiting moderation. Thank you for participating in the discussion.

My point was that generic code should always consider the corner cases. Espcially with a pattern like this which can so easily be wrapped up in a method constructor. In code where you control the horizontal and the vertical there's nothing wrong with taking the view that you'll never trip over the nil/false problem, but in library code you must account for it.

Since a pattern is essentially a subroutine that's executed by a human being, it makes sense for the pattern to at least discuss the potential pitfall.