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

[Louis Pilfold]

Hey

I'd say the disadvantage is that it'd be making Elixir a bigger and more
complex language. I think there's value in having a small core language
that gives users the tools to extend it as required.

And there's always the question what exactly should be a core feature. I
don't use any languages that support inheritance, and thus to be this seems
like an exotic niche feature rather than a core language feature. :)

Cheers,
Louis

On Mon, 28 May 2018, 00:11 Steve Morin,  wrote:

> Re:my prior comments, think it would be good as a add on package for those
> that want to use that.
>
> On May 27, 2018, at 16:00, 'boris kotov' via elixir-lang-core <
> elixir-lang-core@googlegroups.com> wrote:
>
> Hi Louis,
>
> yeah you are right, its something that I am already thinking about.
> I was just wondering, what are the cons of putting it directly into the
> language, as it seems to me, to be a core-language-feature.
>
> Cheers,
> Boris
>
> Am Montag, 28. Mai 2018 00:44:31 UTC+2 schrieb 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-l...@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&D

 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:
>>

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

[Steve Morin]

Re:my prior comments, think it would be good as a add on package for those that 
want to use that.

> On May 27, 2018, at 16:00, 'boris kotov' via elixir-lang-core 
>  wrote:
> 
> Hi Louis,
> 
> yeah you are right, its something that I am already thinking about.
> I was just wondering, what are the cons of putting it directly into the 
> language, as it seems to me, to be a core-language-feature.
> 
> Cheers,
> Boris
> 
> Am Montag, 28. Mai 2018 00:44:31 UTC+2 schrieb 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, 
>>>  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&D
 
>>> 
> On Sun, May 27, 2018 at 11:14 PM, 'boris kotov' via elixir-lang-core 
>  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 optio

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

[Steve Morin]

Feels too much like an inheritance pattern that I don’t think makes sense in a 
clean functional style.  I can see uses for it but feel like it will be abused 
more than it will help.

> On May 27, 2018, at 16:00, 'boris kotov' via elixir-lang-core 
>  wrote:
> 
> Hi Louis,
> 
> yeah you are right, its something that I am already thinking about.
> I was just wondering, what are the cons of putting it directly into the 
> language, as it seems to me, to be a core-language-feature.
> 
> Cheers,
> Boris
> 
> Am Montag, 28. Mai 2018 00:44:31 UTC+2 schrieb 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, 
>>>  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&D
 
>>> 
> On Sun, May 27, 2018 at 11:14 PM, 'boris kotov' via elixir-lang-core 
>  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, 

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

['boris kotov' via elixir-lang-core]

Hi Louis,

yeah you are right, its something that I am already thinking about.
I was just wondering, what are the cons of putting it directly into the 
language, as it seems to me, to be a core-language-feature.

Cheers,
Boris

Am Montag, 28. Mai 2018 00:44:31 UTC+2 schrieb 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-l...@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&D
>>>
>>> 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 fro

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

[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&D
>>
>> 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, vi

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

['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&D
>
> 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
>>  
>> 

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

[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&D

On Sun, May 27, 2018 at 11:14 PM, 'boris kotov' via elixir-lang-core <
elixir-lang-core@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-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/elixir-lang-core/e6a44f9f-a62f-44f2-9e75-1ebec3d298d8%40
> googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGnRm4KFVNKg62Om5ZmKTp%3DNaf7BEdkgSTLw7dbfviLUr5sNZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:8028] Re: Module inheritance

['boris kotov' via elixir-lang-core]

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-core+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.