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/edd529d4-b3ff-4729-a8a9-b0a27fe9c69bn%40googlegroups.com.
