Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Wednesday, 17 June 2020 at 16:01:29 UTC, Paul Backus wrote: A while ago, I collaborated briefly with Adam Kowalski from the Dlang discord server on some code to emulate C++-style argument-dependent lookup in D. Using that code, your example above would be written: Geometry.create(r.extended).measure; Geometry.create(c.extended).measure; Here's a gist with the code, along with a small example: https://gist.github.com/pbackus/0a70419eb8bece52f3a08edfe7b6019b If anyone thinks it's worthwhile, I can toss this up on Dub. Personally, I've never had much use for it in my own projects. Yeah I can see a use for this. If have had to refactor things before because I was hitting this restriction.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Wednesday, 17 June 2020 at 16:01:29 UTC, Paul Backus wrote: [snip] IMO this can be done more elegantly by separating out the code that looks up methods in the current module from the code that does the actual type erasure. A while ago, I collaborated briefly with Adam Kowalski from the Dlang discord server on some code to emulate C++-style argument-dependent lookup in D. Using that code, your example above would be written: Geometry.create(r.extended).measure; Geometry.create(c.extended).measure; Here's a gist with the code, along with a small example: https://gist.github.com/pbackus/0a70419eb8bece52f3a08edfe7b6019b If anyone thinks it's worthwhile, I can toss this up on Dub. Personally, I've never had much use for it in my own projects. The syntax there looks nice (wouldn't hurt to make it even nicer!). Your moduleOf (and associated functions) looks like it shares similar functionality as some of what is in vtableImpl in poly.d (particularly importMixin).
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote:
With a few changes, yes (added missing semicolons, changed
IGeometry to Geometry in `measure`, passed the current module
so tardy can find the UFCS functions, added `@safe pure` to the
UFCS functions:
[...]
void main() {
auto r = Rect(3.0, 4.0);
auto c = Circle(5.0);
Geometry.create!__MODULE__(r).measure;
Geometry.create!__MODULE__(c).measure;
}
IMO this can be done more elegantly by separating out the code
that looks up methods in the current module from the code that
does the actual type erasure.
A while ago, I collaborated briefly with Adam Kowalski from the
Dlang discord server on some code to emulate C++-style
argument-dependent lookup in D. Using that code, your example
above would be written:
Geometry.create(r.extended).measure;
Geometry.create(c.extended).measure;
Here's a gist with the code, along with a small example:
https://gist.github.com/pbackus/0a70419eb8bece52f3a08edfe7b6019b
If anyone thinks it's worthwhile, I can toss this up on Dub.
Personally, I've never had much use for it in my own projects.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Wednesday, 17 June 2020 at 11:46:12 UTC, Atila Neves wrote: [snip] I think these questions are good motivators for making it interface-only since then I don't have to check for data definitions. Makes sense.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Wednesday, 17 June 2020 at 11:31:09 UTC, jmh530 wrote: On Wednesday, 17 June 2020 at 10:04:59 UTC, Atila Neves wrote: [...] Cool. [...] If I'm understanding you correctly, you could modify Polymorphic (and a similar change to VirtualTable) to struct Polymorphic(Interface, InstanceAllocator = DefaultAllocator) if(is(Interface == interface) || is(Interface == class) || is(Interface == struct)) and the current functionality would still work. However, compared to normal inheritance, it would be missing the "base" class's member variables that don't exist in the "derived" one. You also couldn't call the "base" class member functions. Polymorphic is assuming the member functions are all implemented in the instance passed to it, correct? I think these questions are good motivators for making it interface-only since then I don't have to check for data definitions.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Wednesday, 17 June 2020 at 10:04:59 UTC, Atila Neves wrote:
[snip]
I was going to say "it should work" but instead I wrote the
code and... it does. It all falls out of how UFCS works and
usual language rules.
https://github.com/atilaneves/tardy/blob/feb26282608081098134c8846be87d398772ccb0/tests/ut/polymorphic.d#L102
https://github.com/atilaneves/tardy/blob/feb26282608081098134c8846be87d398772ccb0/tests/modules/ufcs/template_.d
Cool.
Am I right that the shared static constructor in vtable means
that there is one vtable for all the instances?
All instances of the same concrete type share the same vtable
pointer, yes. Originally I built the vtable on the spot with
`new` and assigned to each function pointer but then I realised
that was a waste of time and allocations - the vtable is unique
per concrete type.
Are there any technical issues preventing Polymorphism from
accepting a class in addition to an interface?
None. It could even accept a struct, really.
If I'm understanding you correctly, you could modify Polymorphic
(and a similar change to VirtualTable) to
struct Polymorphic(Interface, InstanceAllocator =
DefaultAllocator)
if(is(Interface == interface) || is(Interface == class) ||
is(Interface == struct))
and the current functionality would still work.
However, compared to normal inheritance, it would be missing the
"base" class's member variables that don't exist in the "derived"
one. You also couldn't call the "base" class member functions.
Polymorphic is assuming the member functions are all implemented
in the instance passed to it, correct?
I suppose I was more asking if there were any issues preventing
the ability to get these things to work. In other words,
Polymorphism works with interfaces now and the behavior is like
inheriting from an interface. Could it work for classes (and by
implication structs), such that the behavior is like inheriting
from classes, and not just treating the class like an interface.
In the case of structs, which may be a little simpler to
implement than classes, something as simple as below might be
able to get this functionality working.
static if (Interface == struct) {
Interface base;
alias base this;
}
so that member variables and functions missing from the instance
can get forwarded to the alias this. Though this wouldn't handle
super constructors.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Wednesday, 17 June 2020 at 10:43:35 UTC, Stanislav Blinov wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: Tardy lets users have their cake and eat it too by not making them have to use classes for runtime polymorphism. I've got to ask though. Why "tardy"? Search engines be damned? :) Late binding ;)
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: Tardy lets users have their cake and eat it too by not making them have to use classes for runtime polymorphism. I've got to ask though. Why "tardy"? Search engines be damned? :)
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 15:50:07 UTC, jmh530 wrote: On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote: [snip] Pretty cool, thanks for the fixups. It may make for a good documentation example, in that it may help make clear that you need to pass the module in somehow when dealing with non-member functions (AFAICT). You could include a comment about how it would be different if it were split into separate files. Good point. In your original example, is there any issue if we then make transform a templated non-member function that is generic over types like Adder (maybe there is an enum hasAddableMember that is true for Adder and false for Plus1)? I was going to say "it should work" but instead I wrote the code and... it does. It all falls out of how UFCS works and usual language rules. https://github.com/atilaneves/tardy/blob/feb26282608081098134c8846be87d398772ccb0/tests/ut/polymorphic.d#L102 https://github.com/atilaneves/tardy/blob/feb26282608081098134c8846be87d398772ccb0/tests/modules/ufcs/template_.d Am I right that the shared static constructor in vtable means that there is one vtable for all the instances? All instances of the same concrete type share the same vtable pointer, yes. Originally I built the vtable on the spot with `new` and assigned to each function pointer but then I realised that was a waste of time and allocations - the vtable is unique per concrete type. Are there any technical issues preventing Polymorphism from accepting a class in addition to an interface? None. It could even accept a struct, really.
Re: LDC 1.22.0
On Tuesday, 16 June 2020 at 20:12:12 UTC, kinke wrote:
Glad to announce LDC 1.22 - some highlights:
- Based on D 2.092.1+.
- AArch64: C(++) interop should now be on par with x86_64, and
variadics usable with core.{vararg,stdc.stdarg}.
- Windows hosts: Auto-detection & setup of installed Visual C++
toolchains revamped and newly enabled by default.
- Complete FreeBSD x86_64 support, incl. CI and prebuilt
package.
- @weak functions emulation for Windows targets (and fix for
ELF targets); no COMDATs emission for ELF anymore.
- `pragma(inline, true)` fix when emitting multiple object
files in a single cmdline. This may have a significant impact
on performance (incl. druntime/Phobos) when not using LTO.
- Android: Fix TLS initialization regression (introduced in
v1.21) and potential alignment issues. Now defaulting to
`-linker=bfd`.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.22.0
Thanks to all contributors!
Thank you for your great service to the D community. Your great
work is showing clearly to me that passion itself is a great
reward and motivation. Keep on the great work, D deserves the
only the top
