> > Using @optional_callbacks > I love the idea of this. I think it simplifies a lot of the work and is > still explicit. If this is in place can a callback still have an > implementation? I ask because sometimes it is nice to have the exception > give some larger context of information when an undefined callback is used. > Many times I think a default error is okay, but sometimes I want to provide > the developer with a more in depth explanation. >
So the behaviour definition + __using__macro is how you provide default implementations for callbacks. We currently have no plans for streamlining this system beyond the proposal above. The original way is more explicit about what is overridable and what is > not. Would it be possible to be explicit by changing defoverridable to be > used the same way as def, defmodule, and defimple? The defoverridable feels > like it goes along with the other "def" tokens. > I don't like defoverridable as a function definition because we would need defoverridablemacro and it doesn't play well with function clauses. Remember a function may always have multiple clauses. This is similar to the PS I explain in the original issue. > I like the notation here when it includes that name of the behavior, but > I'm not a fan of the true. I understand that it appears directly above the > header in question, but I like the explicit version. Would this only go > over one clause?, or would it have to be over top of each clause? > Over one clause. Annotations are usually for a single function (and each function is made of multiple clauses). -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JQ5uM6JWOGifCHdFboDYTgKp_NonnW33EYDLg%2BAmsx%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
