Thread overview | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
December 02, 2019 interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
In short use `in(false)` when you `override` a function to inherit the contract, unless you explicitly want to expand the input - which you shouldn't do when implementing an interface! Wrote about it in more details here: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through. destroy if i missed anything lol |
December 02, 2019 Re: interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote:
> Wrote about it in more details here:
>
> http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html
>
> i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through.
Interesting, could be useful, but now you have to remember to add "in(false)".
I wonder if this could somehow be wrapped up in a clean way using meta-programming so you always get the "in(false)"?
|
December 03, 2019 Re: interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote: > Interesting, could be useful, but now you have to remember to add "in(false)". Yeah, it is kinda tempting to propose a language change, where an override method does this by default if nothing else is specified. I think it would probably usually be the right thing to do, and then you'd opt into extending it all the way by doing `in(true)` instead. > I wonder if this could somehow be wrapped up in a clean way using meta-programming so you always get the "in(false)"? I don't think so, contracts are invisible to reflection right now (unless there's a trick I don't know). Maybe a language change is warranted though, I don't really know, especially since this thing is possible today. |
December 03, 2019 Re: interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Tuesday, 3 December 2019 at 02:57:13 UTC, Adam D. Ruppe wrote:
> On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote:
>> Interesting, could be useful, but now you have to remember to add "in(false)".
>
> Yeah, it is kinda tempting to propose a language change, where an override method does this by default if nothing else is specified. I think it would probably usually be the right thing to do, and then you'd opt into extending it all the way by doing `in(true)` instead.
Yes, I agree, if you forget to add a specification then it probably should have the same strictness as the superclass. That is what I would expect.
|
December 03, 2019 Re: interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On 2019-12-03 07:53:48 +0000, Ola Fosheim Grøstad said: > On Tuesday, 3 December 2019 at 02:57:13 UTC, Adam D. Ruppe wrote: >> On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote: >>> Interesting, could be useful, but now you have to remember to add "in(false)". >> >> Yeah, it is kinda tempting to propose a language change, where an override method does this by default if nothing else is specified. I think it would probably usually be the right thing to do, and then you'd opt into extending it all the way by doing `in(true)` instead. > > Yes, I agree, if you forget to add a specification then it probably should have the same strictness as the superclass. That is what I would expect. +1 having to add something explicit to get the superclass contract activated looks weired. In large scale projects this will become a big problem as you can't assume that every developer knows about all the contracts of a superclass. -- Robert M. Münch http://www.saphirion.com smarter | better | faster |
December 03, 2019 Re: interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert M. Münch | On Tuesday, 3 December 2019 at 10:39:08 UTC, Robert M. Münch wrote:
> In large scale projects this will become a big problem as you can't assume that every developer knows about all the contracts of a superclass.
That's the beauty of `override in(false)` - you don't have to know about the superclass. You can use it and it works in all cases.
Though that's also a possible argument for the language change.
|
December 03, 2019 Re: interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On 2019-12-03 13:00:49 +0000, Adam D. Ruppe said: > On Tuesday, 3 December 2019 at 10:39:08 UTC, Robert M. Münch wrote: >> In large scale projects this will become a big problem as you can't assume that every developer knows about all the contracts of a superclass. > > That's the beauty of `override in(false)` - you don't have to know about the superclass. You can use it and it works in all cases. My point was, when the superclass doesn't has an in() contract: Error: function contracts.Derived.test cannot have an in contract when overridden function contracts.Base.test does not have an in contract So, I need to know that the superclass has a contract and that I want to fallback to it. The former is the hard part. > Though that's also a possible argument for the language change. Yes, but only if the superclass has an in() contract. -- Robert M. Münch http://www.saphirion.com smarter | better | faster |
December 03, 2019 Re: interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert M. Münch | On Tuesday, 3 December 2019 at 10:39:08 UTC, Robert M. Münch wrote:
> In large scale projects this will become a big problem as you can't assume that every developer knows about all the contracts of a superclass.
Yes, like if you just want to constrain a signed int to be >=1. If you forget to add it in the subclass it suddenly takes negative ints with no warning...
|
December 03, 2019 Re: interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert M. Münch | On Tuesday, 3 December 2019 at 14:24:15 UTC, Robert M. Münch wrote:
> My point was, when the superclass doesn't has an in() contract:
>
> Error: function contracts.Derived.test cannot have an in contract when overridden function contracts.Base.test does not have an in contract
ooooh geeze I was so focused on inheriting the contract that I didn't even test if it didn't have one at all. So we need a language change anyway.
ugh.
|
December 03, 2019 Re: interfaces and contracts - new pattern | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Tuesday, 3 December 2019 at 14:40:21 UTC, Adam D. Ruppe wrote:
> ooooh geeze I was so focused on inheriting the contract that I didn't even test if it didn't have one at all. So we need a
Maybe also test with D interfaces? I suppose they have the same behaviour as superclasses?
Anyway, I think most programmers struggle with covariant/contravariant parameters... I certainly have to stop up and ponder for a while to figure out the semantics when hitting such. So I tend to avoid it... :-P :-)
|
Copyright © 1999-2021 by the D Language Foundation