How to extend kernel module without aliasing/importing it?

There’s nothing automatically imported besides Kernel in elixir. You either need to import explicitly or have a macro doing the import.

Yup. Elixir is explicit about imports by design, with Kernel being the single exception. You will need to define some sort of MyProject.Kernel and import it wherever you want to use its functions.

Just BTW, the is_nil/1 function does not choose is_nil over nil? half-hazardly, this is in line with a particular Elixir naming convention:

Type checks and other boolean checks that are allowed in guard clauses are named with an is_ prefix.

Note that type checks that are not valid in guard clauses do not follow this convention. For example: Keyword.keyword?/1.

To follow this convention that other developers in your project may rely upon, you would either want to name this function empty?/1, or implement it as a guard.

That implementation will be different than the functional version, but can be used anywhere guards or allowed! To translate your example is_empty/1, it would look something like:

defmodule MyProject.Kernel do
  defguard is_empty(thing) when thing in ["", nil, []]
end

Finally, as a design note, outside of extenuating circumstances, I would treat it as a code smell that you are often checking if thing in ["", nil, []]. The implication is that you are regularly uncertain if your data is a string, list, or null value; all throughout your program.

It would be hard with no context to diagnose why this is happening or propose a better pattern, but I would keep on this part of your code! You may find an opportunity to coerce the variable type of an input into your program into a known single type close to where it is received, then confidently refactor a lot of less-confident, unassertive code. Then theoretically you could handle “empty cases” throughout just by matching against one of "", [], or nil.

Thank you (both) for the responses!

As for the data, most checks are if a in ["", nil] (without the list), because for those fields in the database we can have nil or the empty string. In the database we want the difference, since nil is the default (aka: never set) and the empty string can be ‘set to empty’, but was set none the less.

We find it valuable to have that distinction in the db, but in the application it doesn’t matter most of the time.

Thanks again for the input, I’ll take this feedack to our team!

That’s a very common situation, makes perfect sense!

Generally, rather than scattering these checks across my codebase, I’d try to exert them within modules singly responsible for interacting with ecto structs that have these quirks—for example, perhaps inside the schema modules themselves with changesets, or a context module that validates and navigates all of this conditional logic in one place.

Specific to this common empty-string data-model case however, I’d propose a simpler way to handle this—at least, if your team is willing to make a schema change, and using postgres—other dbs may have similar solutions but I’m not sure:

ALTER TABLE thing ADD CHECK (field <> '');

This simply ensures that a given field can not be an empty string.

Whether or not my text fields are NOT NULL these days, I simply do not allow empty strings in my data model. It never makes sense in the domain layer, causes semantic confusion in nullable columns, and as you experience, pushes a whole bevy of edge case handling to application logic.

Empty strings are the opposite of data, moreso than NULLs! Get’em out of your database! Make invalid states unrepresentable! Have your nullable changesets cast "" to nil once, your non-nullable ones error, and never think about it again.

The one exception is maybe if I have a user-entered free-form text area like a description and I want to discern between “never interacted with” and “had a value manually deleted”. But that’s really something that should be modeled differently, with change tracking or an enum-type state machine.

Edit: I just noticed your mention that

Feel free to ignore my rant against empty strings, then! If your team finds signal in them, by all means normalize in the application layer rather than the data model! @D4no0 's suggestion is a great one.

I’ve dealt with this a few times also in some legacy codebases and the best solution I found is to use custom Ecto types that know how to deal with these values, you skip the step where you have to deal manually with these kind of checks.

Man, this forum is unforgiving for inadvertent submits! But that is neither here not there.

I’m gonna triple down on custom Ecto types.

If they happen to sound scary, they really aren’t. If your team is resistant at all, do a book club (or “doc club” if you will) on them and you’ll realize they really aren’t.

EDIT: aaaand I need to edit again, because clearly I was responding to OP and not you, D4no0.

I don’t see why there would be any difficulties or traction with custom ecto types, for example for strings that are not normalized in database you could do:

defmodule NonNormalizedString do
  use Ecto.Type
  def type, do: :string

  def cast(str) when is_binary(str), do: str
  def cast(_), do: :error

  def load(str) when is_empty(str), do: nil
  def load(str), do: str

  # Ideally you should normalize data before insertion, this assumes data
  # was not created by this codebase
 def dump(str) when is_binary(str), do: str
 def dump(_), do: :error
end

Where is_empty can be a custom guard that can detect all these shifty types, or you could do that with a function as above.

You’re a missing a guard here.

Me neither but I’ve dealt with people who are resistant.