Re: [elixir-core:8030] Re: Module inheritance

2018-05-27 Thread Louis Pilfold 
Hi Boris

Regardless of whether this functionality is desirable, one could implement
functionality like this using Elixir's macro system. As such there is no
need for it to be a core language feature.

If you want it why not implement it and release it as a Hex package? That
way you get the feature you want, and of it proves to be useful others can
also make use of it too.

Cheers,
Louis

On Sun, 27 May 2018, 23:20 'boris kotov' via elixir-lang-core, <
elixir-lang-core@googlegroups.com> wrote:

> No, I meant this as a language feature, for users, to re-use
> functionalities from other modules by extending them.
> For sure, if you are going to extend something, you should know what the
> origin is doing, and why you are extending it.
> I am thinking about some community packages, where some of your special
> use-cases are not covered, and you would like to "extend" it, not fully
> reimplement it.
> The same goes for already existing erlang packages, where you want to
> touch some parts and let the rest do its job.
> IMHO "use" is actually meant for this kind of extension, but its very
> strict and limited by the actual implementation, which is good actually.
> Extend on the other hand would be more flexible, which also a good thing :)
>
> Documentation, I see, might be a problem, if you want to publish it. I am
> not sure, but I think it should be possible to take the current
> documentation from the origin on the fly while compiling, maybe I am wrong.
>
> Am Sonntag, 27. Mai 2018 23:23:44 UTC+2 schrieb José Valim:
>
>> Hi Boris,
>>
>> Simply because it is a pattern we don't want to encourage, as it fully
>> couples a module to another one.
>>
>> And there are questions such as documentation. Are you going to document
>> the delegated functions? If not, why not? Should we copy the delegations?
>> Then the examples are likely outdated.
>>
>> If you feel like you need to delegate a whole module, it is better to
>> re-evaluate the solution and discuss the problem, as it is very unlikely in
>> Elixir.
>>
>
>>
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R
>>
>> On Sun, May 27, 2018 at 11:14 PM, 'boris kotov' via elixir-lang-core <
>> elixir-l...@googlegroups.com> wrote:
>>
> Hey José,
>>>
>>> I am the guy, who just asked about defdelegate (n-ary) (if you still can
>>> remember)
>>> And what I was actually looking for is `extends SomeModule` feature,
>>> instead of delegating all functions one-by-one * arity.
>>>
>>> Just wondering, why this feature is still not in the core :) ?
>>>
>>> Thanks,
>>> Boris
>>>
>>>
>>> Am Freitag, 1. Februar 2013 22:57:12 UTC+1 schrieb José Valim:

 The current behaviour is correct. Ideally we would have "excluding end"
 ranges, but we don't. I have updated the gist to consider zero arity
 functions:

 https://gist.github.com/ff41078606cfe0e55eaf


 *José Valim*
 www.plataformatec.com.br
 Skype: jv.ptec
 Founder and Lead Developer


 On Fri, Feb 1, 2013 at 11:10 AM, Yurii Rashkovskii 
 wrote:

> It is. It was the other way around some time ago
> On Feb 1, 2013 10:09 AM, "Oren Ben-Kiki"  wrote:
>
>> A correction: 1..arity doesn't work when arity is 0 (it actually
>> generates [1,0] instead of []). Is this the expected behavior?
>>
>>
>> On Mon, Jan 28, 2013 at 11:29 PM, Oren Ben-Kiki 
>> wrote:
>>
>>> I agree this should be used very sparingly; in my case, there's a
>>> single specific case I want to use it for in my system. That said, it is
>>> much cleaner to do it the way you provided - thanks!
>>>
>>>
>>> On Monday, January 28, 2013 11:19:54 PM UTC+2, José Valim wrote:

 I don't particularly encourage extends but it can be easily
 achieved as:

 https://gist.github.com/ff41078606cfe0e55eaf

 *José Valim*
 www.plataformatec.com.br
 Skype: jv.ptec
 Founder and Lead Developer

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "elixir-lang-core" group.
>>> To unsubscribe from this group, send email to
>>> elixir-lang-co...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
> --
> 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

Re: [elixir-core:8030] Re: Module inheritance

2018-05-27 Thread 'boris kotov' via elixir-lang-core 
No, I meant this as a language feature, for users, to re-use 
functionalities from other modules by extending them.
For sure, if you are going to extend something, you should know what the 
origin is doing, and why you are extending it.
I am thinking about some community packages, where some of your special 
use-cases are not covered, and you would like to "extend" it, not fully 
reimplement it.
The same goes for already existing erlang packages, where you want to touch 
some parts and let the rest do its job.
IMHO "use" is actually meant for this kind of extension, but its very 
strict and limited by the actual implementation, which is good actually.
Extend on the other hand would be more flexible, which also a good thing :)

Documentation, I see, might be a problem, if you want to publish it. I am 
not sure, but I think it should be possible to take the current 
documentation from the origin on the fly while compiling, maybe I am wrong.

Am Sonntag, 27. Mai 2018 23:23:44 UTC+2 schrieb José Valim:
>
> Hi Boris,
>
> Simply because it is a pattern we don't want to encourage, as it fully 
> couples a module to another one.
>
> And there are questions such as documentation. Are you going to document 
> the delegated functions? If not, why not? Should we copy the delegations? 
> Then the examples are likely outdated.
>
> If you feel like you need to delegate a whole module, it is better to 
> re-evaluate the solution and discuss the problem, as it is very unlikely in 
> Elixir.
>
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
> On Sun, May 27, 2018 at 11:14 PM, 'boris kotov' via elixir-lang-core <
> elixir-l...@googlegroups.com > wrote:
>
>> Hey José,
>>
>> I am the guy, who just asked about defdelegate (n-ary) (if you still can 
>> remember)
>> And what I was actually looking for is `extends SomeModule` feature, 
>> instead of delegating all functions one-by-one * arity.
>>
>> Just wondering, why this feature is still not in the core :) ?
>>
>> Thanks,
>> Boris
>>
>>
>> Am Freitag, 1. Februar 2013 22:57:12 UTC+1 schrieb José Valim:
>>>
>>> The current behaviour is correct. Ideally we would have "excluding end" 
>>> ranges, but we don't. I have updated the gist to consider zero arity 
>>> functions:
>>>
>>> https://gist.github.com/ff41078606cfe0e55eaf
>>>
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Lead Developer
>>>
>>>
>>> On Fri, Feb 1, 2013 at 11:10 AM, Yurii Rashkovskii  
>>> wrote:
>>>
 It is. It was the other way around some time ago
 On Feb 1, 2013 10:09 AM, "Oren Ben-Kiki"  wrote:

> A correction: 1..arity doesn't work when arity is 0 (it actually 
> generates [1,0] instead of []). Is this the expected behavior?
>
>
> On Mon, Jan 28, 2013 at 11:29 PM, Oren Ben-Kiki  
> wrote:
>
>> I agree this should be used very sparingly; in my case, there's a 
>> single specific case I want to use it for in my system. That said, it is 
>> much cleaner to do it the way you provided - thanks!
>>
>>
>> On Monday, January 28, 2013 11:19:54 PM UTC+2, José Valim wrote:
>>>
>>> I don't particularly encourage extends but it can be easily achieved 
>>> as:
>>>
>>> https://gist.github.com/ff41078606cfe0e55eaf
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Lead Developer
>>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "elixir-lang-core" group.
>> To unsubscribe from this group, send email to 
>> elixir-lang-co...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
> -- 
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
 -- 
 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.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

>>>
>>> -- 
>> 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/e6a44f9f-a62f-44f2-9e75-1ebec3d298d8%40googlegroups.com
>>  
>>