> 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/6e3ec755-5d08-4515-b23d-54bd42165827n%40googlegroups.com.
