On Tuesday, 3 December 2019 at 17:19:11 UTC, Adam D. Ruppe wrote:
You could conceivably write a child class that wraps or
converts. For example, perhaps:
class Serializer {
void serialize(Serializable s) {}
}
class ExtendedSerializer: Serializer {
override void serialize(Object o) {
On Tuesday, 3 December 2019 at 17:17:15 UTC, Meta wrote:
Which is still open, but Iain ran into stack corruption issues
when compiling with the -m64 flag... and no further progress.
So I guess it's just a matter of the bug not being fixed.
That's surprising. It could perhaps just use my
On Tuesday, 3 December 2019 at 17:10:04 UTC, Meta wrote:
On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote:
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
On Tuesday, 3 December 2019 at 17:10:04 UTC, Meta wrote:
Am I mistaken as to what the defect was, or as to whether it
was fixed, or both?
I don't think they ever changed it - the code in the original
link there shows the current behavior.
On Tuesday, 3 December 2019 at 16:03:18 UTC, Ola Fosheim Grøstad
wrote:
But this doesn't work in D.
That's my point - it is unsound in the static type system and D
correctly rejects it. Might work in a dynamic language, but not
in static.
Yes, but when do you need to do it? So it is
On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote:
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:
On Tuesday, 3 December 2019 at 16:03:18 UTC, Ola Fosheim Grøstad
wrote:
comes to virtual function parameters. Then again, I think
overriding the implementation of the subclass is kinda ugly.
That made no sense, I meant superclass...
On Tuesday, 3 December 2019 at 15:25:19 UTC, Adam D. Ruppe wrote:
On the parameters side it is a little more confusing, but it
still makes sense:
abstract class Generic {
void generic(Generic g);
}
class Specialized : Generic {
override void generic(Specialized g) {}
}
But this
On Tuesday, 3 December 2019 at 15:26:10 UTC, Ola Fosheim Grøstad
wrote:
Also the use of the term "covariant" here is confusing to me:
Yeah, to be honest, I forget what the terms mean, so I tend to
avoid them. like my last email just talked about specialization
and implicit casts which I
On Tuesday, 3 December 2019 at 15:12:46 UTC, Ola Fosheim Grøstad
wrote:
But I was thinking of contravariant/covariant parameters on
virtual functions.
those too. I mostly use it with things like a clone method:
interface Cloneable {
Cloneable clone();
}
class MyClass : Cloneable {
On Tuesday, 3 December 2019 at 15:12:46 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 3 December 2019 at 14:51:58 UTC, Adam D. Ruppe
wrote:
Maybe, but it is pretty sound once you get to know it.
You mean contracts? Yes. But I was thinking of
contravariant/covariant parameters on virtual
On Tuesday, 3 December 2019 at 14:51:58 UTC, Adam D. Ruppe wrote:
Maybe, but it is pretty sound once you get to know it.
You mean contracts? Yes. But I was thinking of
contravariant/covariant parameters on virtual functions. Doesn't
work with overloading though, so D only has it on return
On Tuesday, 3 December 2019 at 14:45:28 UTC, Ola Fosheim Grøstad
wrote:
Maybe also test with D interfaces? I suppose they have the same
behaviour as superclasses?
Yeah, I did that (there's a unittest in the blog source for it,
that's what shows under the example section). It works nicely.
I
On Tuesday, 3 December 2019 at 14:40:21 UTC, Adam D. Ruppe wrote:
h 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
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
h geeze I was
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
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
On 2019-12-03 07:53:48 +, 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
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
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
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
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
22 matches
Mail list logo
