In cases, the following code may exist (real production code):
```
defmodule MyModule.Error do
# notice here
if Code.ensure_loaded?(Ecto) do
alias MyModule.Error.{ChangesetParser, ErrorList}
@spec new(Ecto.Changeset.t()) :: MyModule.Error.ErrorList.t()
def new(%Ecto.Changeset{} = changeset) do
changeset
|> ChangesetParser.parse()
|> ErrorList.new()
end
end
end
```
Based on your proposal, use the following structure:
```elixir
features: [
hls: [
dependencies: [],
modules: []
]
]
```
How could we configure it to depend on `Ecto` only for that function?
On Monday, May 15, 2023 at 2:22:51 PM UTC-4 christ...@gmail.com wrote:
> > Is there any particular issue with the information I shared that
> wouldn't help with the situation?
>
> Your thoughts are compelling and merit discussion!
>
> It's just that there's a slippery slope in proposal conversations: between
> discussing *a specific* proposal (in this instance, Michal's original
> well-formulated one), and brainstorming and iterating on feedback to arrive
> at *a new *specific proposal. It's a fuzzy line, but one we have to draw
> at some point in any conversation as it goes on, as this mailing list is
> only for specific proposals.
>
> It's nothing personal—it's just time to move conversation around building
> a new proposal to a more productive discussion-oriented forum, such as the
> Elixir Forums, or direct chat/emails with others working on a new idea!
> On Sunday, May 14, 2023 at 3:59:06 PM UTC-4 yordis...@gmail.com wrote:
>
>> I thought that the ideas were around the topic. Is there any particular
>> issue with the information I shared that wouldn't help with the situation?
>>
>> On Sunday, May 14, 2023 at 3:33:30 PM UTC-4 José Valim wrote:
>>
>>> No worries, I didn't interpret it as a command. But it is clear there is
>>> an expectation issue: this mailing list should focus on concrete features
>>> and implementations. Once someone submits a proposal here, they are
>>> probably expecting a yes, no (and why so), or what needs to be
>>> considered/improved for the proposal to be accepted. So all feedback in
>>> here has been direct (and historically it has not been a problem).
>>>
>>> I recommend the Elixir Forum if the goal is to bounce ideas and explore
>>> the problem space. We (the Elixir team) already have a lot on our hands and
>>> we probably won't be able to develop ideas into full proposals. So I don't
>>> want your trust to be misplaced. :)
>>>
>>> > if we make assumptions and take the position of "it is possible
>>> today," how could we discuss the trade-offs?
>>>
>>> The point of saying "it is possible today" is that, if you are going to
>>> propose something new, then at least it needs to be compared to what is
>>> possible today and explain how it improves on that. This, alongside the
>>> problem statement, is very important to ensure we are all on the same page.
>>>
>>> On Sun, May 14, 2023 at 8:08 PM Yordis Prieto <yordis...@gmail.com>
>>> wrote:
>>>
>>>> > Here is the issue: the proposal has not elaborated on how those
>>>> problems will be tackled (outside of dependency management).
>>>>
>>>> I wasn't trying to be in Solution-space, just sharing some ideas and
>>>> pain points and trying to figure out if they could be solved
>>>> simultaneously.
>>>>
>>>> > And don’t ask us to figure it out
>>>>
>>>> When I said, "I trust you will figure it out," I trusted you would do
>>>> the right thing. I didn't give you any command. My apologies if it came
>>>> across as a Command, but I intended to say, "I trust you, but please don't
>>>> discourage the ideas making assumptions about it" That's all.
>>>>
>>>> > It is not that we don’t care or didn’t think about it. Those are
>>>> different trade-offs, with their strengths and weaknesses, and if we want
>>>> to copy features from Rust, then those trade-offs need to be taken into
>>>> account as part of a complete proposal.
>>>>
>>>> I don't disagree with that at all. That was the intent; discuss it. But
>>>> if we make assumptions and take the position of "it is possible today,"
>>>> how
>>>> could we discuss the trade-offs?
>>>>
>>>> > Application.ensure_feature would most likely be a wrapper around
>>>> config.
>>>>
>>>> I am not sure about the technicality underneath, but I was assuming
>>>> that we can't just do that unless we reserve some key or something like
>>>> that, so I was thinking in a completely different ets table for it, but
>>>> sure, it could "feel" as simple as Config module, why not.
>>>>
>>>> One way I was thinking of adding a key under the `mix.exs` to be able
>>>> to have information:
>>>>
>>>> ```
>>>> defmodule H264.MixProject do
>>>> use Mix.Project
>>>>
>>>> def project do
>>>> [features: [:parser, :encoder, :native]] # maybe be able to add
>>>> description for them also?!
>>>> end
>>>> end
>>>> ```
>>>>
>>>> Be able to use that information when calling
>>>> `Application.ensure_feature`. It would be just the Config API since it
>>>> would require checking `mix.exs` and/or another ets table with the
>>>> information about the feature. I guess that registering the Features at
>>>> compile time instead of being statically defined in the `mix.exs` would
>>>> become harder. I am unsure if that would be a good idea.
>>>>
>>>> ExDoc and the Mix.Deps task could read such information to require
>>>> dependencies or have documentation about it. It could be used behind
>>>> `Config` package under another macro:
>>>>
>>>> ```
>>>> import Config
>>>> feature :h264, encoder: true
>>>> ```
>>>>
>>>> Or don't do that at all and you only get to activate them using `deps`
>>>> and mess around with `Mix.env()` to correctly configure the features.
>>>>
>>>> Probably activating "statically" in the mix.exs would be simple and
>>>> easier to deal with.
>>>>
>>>> defmodule MyApp.MixProject do
>>>> use Mix.Project
>>>>
>>>> def project do
>>>> [
>>>> deps: [
>>>> {:h264, "~> 0.10.0", features: [:encoder]}
>>>> ]
>>>> ]
>>>> end
>>>> end
>>>>
>>>>
>>>> On Sunday, May 14, 2023 at 3:18:01 AM UTC-4 michal...@gmail.com wrote:
>>>>
>>>>> Sure thing, I just wrote as I thought that maybe you will say: that's
>>>>> a good idea, we were thinking about it, we had similar problems etc. etc.
>>>>>
>>>>> But because of a lot of questions and doubts it's clear that's the
>>>>> requester responsibility to propose detailed description of the API, take
>>>>> into account all pros and cons, describe how they will affect the whole
>>>>> ecosystem and whether the requested feature fits into the language
>>>>> concepts
>>>>>
>>>>> niedz., 14 maj 2023, 08:58 użytkownik José Valim <jose....@dashbit.co>
>>>>> napisał:
>>>>>
>>>>>> One addition: “features” makes sense for Rust because the contents of
>>>>>> its “module body” cannot be dynamic as in Elixir. So if they want to
>>>>>> provide this feature in the first place, it must be done as part of the
>>>>>> compiler.
>>>>>>
>>>>>> Elixir can execute any Elixir code when defining modules, which is
>>>>>> why it is possible to implement these features today without additional
>>>>>> work in the compiler.
>>>>>>
>>>>>> It is not that we don’t care or didn’t think about it. Those are
>>>>>> different trade-offs, with their own strengths and weaknesses, and if we
>>>>>> want to copy features from Rust, then those trade-offs need to be taken
>>>>>> into account as part of a complete proposal.
>>>>>>
>>>>>> --
>>>>>>
>>>>> 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-co...@googlegroups.com.
>>>>>>
>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LeSido9jqm%3DKBwkwCh7%3DQFJeORGata2ertcJChzh_ezQ%40mail.gmail.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LeSido9jqm%3DKBwkwCh7%3DQFJeORGata2ertcJChzh_ezQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>> 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-co...@googlegroups.com.
>>>>
>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/elixir-lang-core/b1519f28-ed13-43d1-88a5-64ba6d909e18n%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/b1519f28-ed13-43d1-88a5-64ba6d909e18n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
--
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/0d6c0925-4394-43e3-a227-8b43ac10dc3an%40googlegroups.com.
