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.pri...@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-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
> <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/CAGnRm4JcRGuScod5Fy1rAGpfkUE6kU8mBptyQiTKFzusRWmtCQ%40mail.gmail.com.
