To be fair, writing code like this is perfectly fine, if you're not concerned about performance (in the area of code that this is written in).
I find for my own code that I'll typically write something in a clean but possibly inefficient way, and the profile and optimize where I find bottlenecks. Conversely, you'll find the trend in Julia mainline is to write very efficient code for the core system, and remove or discourage design patterns which produce inefficient code. Cheers! Kevin On Mon, Feb 8, 2016 at 8:13 PM, Jacob Quinn <[email protected]> wrote: > The problem with that proposition is that it introduces type instability. > i.e. the user would be tempted to write code like Michael's original > example like > > LeapDay(yr) = isLeapYr(yr) ? Date(yr,2,29) : Nullable{Date}() > > where the function `LeapDay` can actually return two different, distinct > types: `Date` or `Nullable{Date}`. Those familiar with efficient codegen > know that these kinds of type instabilities kill code performance. > > -Jacob > > On Mon, Feb 8, 2016 at 8:55 PM, Christopher Alexander <[email protected]> > wrote: > >> I really like that construction! >> >> >> On Monday, February 8, 2016 at 10:49:41 PM UTC-5, Greg Plowman wrote: >>> >>> If only Nullables can be null, could we formally define this? >>> >>> isnull(x::Nullable) = x.isnull # already defined in nullable.jl >>> isnull(x) = false # extra definition for everything >>> else >>> >>> >>> >>>> isnull( lp15 ) --> true >>>> isnull( lp16 ) --> MethodError: `isnull` has no method matching >>>> isnull( ::Date ) >>>> >>> >>> >
