> 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-core+unsubscr...@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.
