Re: How do you return a subclass instance from a base class method?
On Thursday, 17 November 2022 at 05:34:49 UTC, zjh wrote: On Thursday, 17 November 2022 at 04:25:13 UTC, Daniel Donnelly, Jr. wrote: ... `crtp`, will it work? Can't use CRTP, because once you choose a derived class to pass into the template system, how do you pass in subclasses of that class and so on...
Re: How do you return a subclass instance from a base class method?
On Thursday, 17 November 2022 at 05:21:05 UTC, MorteFeuille123 wrote: On Thursday, 17 November 2022 at 04:25:13 UTC, Daniel Donnelly, Jr. wrote: [...] You can use TypeInfoClass: [...] I don't get it - you never made use of b1 or b2...
Re: Is defining get/set methods for every field overkill?
On 11/16/22 20:39, thebluepandabear wrote: > I am debating whether or not I should add getter methods to these > properties. If you are debating, then the answer is easy: you should not. :) Less code written means less bugs, more cohesion, easier refactoring, cleaner code, all good stuff... Even if a design requires e.g. a 'length' method, the default one should be a getter. A setter will come in the future only if 'length = 42' is clearly better than e.g. 'expandTo(42)'. > in other languages like Java it is a good practice: I've seen so many tutorials where any user-defined type immediately defines getters and setters. It is never good style to do that. There are good examples of where doing that is clearly wrong. For example, can a Date class really provide a setMonth() setter? It would be so wrong, I don't even know where to begin. (I remember talks by Kevlin Henney where he would use that example.) The guidelines I follow are simple in the following order: - Don't write any code until it makes sense :) - Don't write a getter until it makes sense - Don't write a setter until it makes sense Ali
Re: Is defining get/set methods for every field overkill?
I wouldn't bother. They are const, they can't change. Nothing to protect, nothing to synchronize.
Re: How do you return a subclass instance from a base class method?
On Thursday, 17 November 2022 at 04:25:13 UTC, Daniel Donnelly, Jr. wrote: ... `crtp`, will it work?
Re: How do you return a subclass instance from a base class method?
On Thursday, 17 November 2022 at 04:25:13 UTC, Daniel Donnelly,
Jr. wrote:
I have SubclassOf derived from PosetRelation. For any poset
relation, the transitivity law applies, however, I'd like to
return the correct type:
How does one accomplish this in D? Because PosetRelation
doesn't know about SubclassOf, in general.
You can use TypeInfoClass:
```d
class Base
{
}
class Derived : Base
{
}
Object newDerivedFromTi(Base b)
{
return typeid(b).create();
}
void main(string[] args)
{
Base b = new Base;
Base d = new Derived;
assert(cast(Derived)newDerivedFromTi(d));
}
```
But that only works with default constructors, i.e no parameters.
Another way is to define a virtual function in the Base:
```d
class Base
{
Object createMostDerived(Base b1, Base b2)
{
return new typeof(this);
}
}
class Derived : Base
{
override Object createMostDerived(Base b1, Base b2)
{
return new typeof(this);
}
}
Object newDerivedFromTi(Base b)
{
return b.createMostDerived(b, b);
}
void main(string[] args)
{
Base b = new Base;
Base d = new Derived;
assert(cast(Derived)newDerivedFromTi(d));
}
```
assuming the PosetRelation (here called Base) actually cary the
SubclassOf type (here called Derived).
Re: How do you return a subclass instance from a base class method?
```
PosetRelation transitivity(PosetRelation R, PosetRelation S)
{
// These if conditions are typically ordered from easiest to
// most involved-to-check.
if (R.op == S.op &&
is(typeof(R) == typeof(S)) &&
R.right == S.left)
{
return new typeof(R)(
R.left, S.right,
by("transitivity of " ~ R.op)); // Proof by this
axiom
}
return null;
}
```
Not sure if that would work yet. Have to test it.
Is defining get/set methods for every field overkill?
I am creating a TUI library and I have a class with the following
constant fields:
```
class Label : Renderable {
const string text;
const TextAlignment textAlignment;
const Color color;
this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
this.dimensions = dimensions;
this(text, textAlignment, color);
}
this(string text, TextAlignment textAlignment, Color color) {
this.text = text;
this.textAlignment = textAlignment;
this.color = color;
}
override Cell[] render() const {
Cell[] cells;
for (int x = 0; x < 0 + text.length; ++x) {
cells ~= Cell(Coordinates(x, 0), text[x], color);
}
return cells;
}
}
```
I am debating whether or not I should add getter methods to these
properties. On one hand, it will inflate the codebase by a lot,
on the other hand -- in other languages like Java it is a good
practice:
```
class Label : Renderable {
private const string text;
private const TextAlignment textAlignment;
private const Color color;
this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
this.dimensions = dimensions;
this(text, textAlignment, color);
}
this(string text, TextAlignment textAlignment, Color color) {
this.text = text;
this.textAlignment = textAlignment;
this.color = color;
}
string getText() const {
return text;
}
TextAlignment getTextAlignment() const {
return textAlignment;
}
Color getColor() const {
return color;
}
override Cell[] render() const {
Cell[] cells;
for (int x = 0; x < 0 + text.length; ++x) {
cells ~= Cell(Coordinates(x, 0), text[x], color);
}
return cells;
}
}
```
It's not a lot of code that has been added but if you have a
class with say 10 different fields, adding getter methods would
definitely increase the code size by a lot, so what are you guys
thoughts on this?
How do you return a subclass instance from a base class method?
I have SubclassOf derived from PosetRelation. For any poset
relation, the transitivity law applies, however, I'd like to
return the correct type:
```
PosetRelation transitivity(PosetRelation R, PosetRelation S)
{
if (R.op == S.op)
{
if (R.right is S.left)
return new SubclassOf(R.left, S.right);
}
return null;
}
```
How does one accomplish this in D? Because PosetRelation doesn't
know about SubclassOf, in general.
Re: Can we ease WASM in D ?
Thanks Adam, H. S., max for your point of view On Wednesday, 16 November 2022 at 23:23:48 UTC, Adam D Ruppe wrote: On Wednesday, 16 November 2022 at 23:16:26 UTC, H. S. Teoh wrote: You mean with Phobos and everything included? I think there may be issues with that... Yes that would be really fantastic to get those enhancement. As example I see this wasm framework wrote in rust: https://github.com/yewstack/yew Get a such framework in D wold be helpful
Re: Can we ease WASM in D ?
On Wednesday, 16 November 2022 at 23:16:26 UTC, H. S. Teoh wrote: You mean with Phobos and everything included? I think there may be issues with that... Yes, this is a problem, but I think I have a solution: defer GC runs until javascript is running. There's also some llvm features that might fix it. If I had a spare day I think I could play with it. Which actually gave me the idea of a D-based framework that uses compile-time introspection, etc., to auto-generate the necessary JS glue code (e.g., as a pre-compile step[1]) so that the user does not actually have to write any JS manually for things to work. Sebastiaan Koppe generates the D/JS glue code from web standards. I've done it more dynamically inside D itself (exposing an `eval` hook on the JS side). Sebastiaans: https://github.com/skoppe/spasm mine: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_10.html Actually pretty easy to solve.
Re: Can we ease WASM in D ?
On Wed, Nov 16, 2022 at 10:51:31PM +, bioinfornatics via Digitalmars-d-learn wrote: > Dear community, > > I look some day ago to the D wasm page: > -> https://wiki.dlang.org/Generating_WebAssembly_with_LDC > > And since then I ask myself can we at compile time convert a D code > to an extern C code for wasm ? > > Indeed, if a library/framework would wrap this to let end user write > his code in plain D that would be awesome. You mean with Phobos and everything included? I think there may be issues with that... because the current WASM does not define a memory management mechanism, so you'd have to convert the GC implementation to work with WASM. Which would have issues with deployment because AIUI currently WASM still requires Javascript to initiate running it; if druntime needs special handling, for example, then you'd have to worry about coordinating with any JS code that the user may also wish to deploy, for example. There are also language constructs that may not be supportable, like exceptions that propagate beyond the JS/WASM boundary (although if we add a layer of indirection to D functions called from JS, this might be possible to shoehorn into a semblance of working). I did actually play with this a week or two ago; and found that it was actually quite difficult to get meaningful native code (D or otherwise) off the ground, because of the currrently mandatory Javascript component that need not only to load and initialize the WASM module, but also to interface with various browser APIs --- since WASM cannot call any of them directly, but has to go through a JS export/import API. String support also needs a lot of boilerplate. Which actually gave me the idea of a D-based framework that uses compile-time introspection, etc., to auto-generate the necessary JS glue code (e.g., as a pre-compile step[1]) so that the user does not actually have to write any JS manually for things to work. [1] I.e., there'd be a special D helper tool that imports your user D code and performs introspection on it, and spits out JS glue code at runtime. So you'd run this as part of your build, and it creates the necessary JS file(s) that you need to insert into your HTML; in the meantime, you run a separate build command to compile the user D code into WASM. (This is why dub seriously needs to break out of its single executable modus operandi -- I don't think this can be easily bundled with dub right now.) Having this tool is essential to making D's WASM experience tolerable; currently the insane amounts of JS boilerplate you have to write in order to get non-trivial D code off the ground is ridiculous. Trying to write a WASM function that does string processing, for example, requires a ton of hacks to work around the lack of a built-in string type. D could totally automate this crap away by having a wrapper tool that introspects your D code at compile-time and spits out the necessary JS boilerplate and any other needed shims in order to get this to work with a minimum of fuss. Also, interfacing with browser APIs like WebGL also needs to be doable with a minimum of fuss, which currently isn't possible because of the unavoidable JS component with its associated boilerplate. T -- Hey, anyone can ignore me and go ahead and do it that way. I wish you the best of luck -- sometimes us old coots are dead wrong -- but forgive me if I'm not going to be terribly sympathetic if you ignore my advice and things go badly! -- Walter Bright
Re: Can we ease WASM in D ?
On Wednesday, 16 November 2022 at 23:00:40 UTC, Adam D Ruppe wrote: On Wednesday, 16 November 2022 at 22:51:31 UTC, bioinfornatics wrote: [...] It would be pretty cool if you could just mark `@wasm` on a function and have it magically convert... the dcompute thing i *think* does something like this. but im not sure. [...] What I've done before (including the webassembly.arsdnet.net website) is have the server call the compiler as-needed when requesting the file, which makes it feel pretty transparent. You might want to do that too, it'd be on the file level instead of on the function level but it works. This is what it does, albeit with a pretty wacky pipeline because GPUs be crazy.
Re: Can we ease WASM in D ?
On Wednesday, 16 November 2022 at 22:51:31 UTC, bioinfornatics wrote: And since then I ask myself can we at compile time convert a D code to an extern C code for wasm ? It would be pretty cool if you could just mark `@wasm` on a function and have it magically convert... the dcompute thing i *think* does something like this. but im not sure. Indeed, if a library/framework would wrap this to let end user write his code in plain D that would be awesome. So did you think it is possible to do it by using metaprogramming, mixin, mixin template, mixin string … ? What I've done before (including the webassembly.arsdnet.net website) is have the server call the compiler as-needed when requesting the file, which makes it feel pretty transparent. You might want to do that too, it'd be on the file level instead of on the function level but it works.
Can we ease WASM in D ?
Dear community, I look some day ago to the D wasm page: -> https://wiki.dlang.org/Generating_WebAssembly_with_LDC And since then I ask myself can we at compile time convert a D code to an extern C code for wasm ? Indeed, if a library/framework would wrap this to let end user write his code in plain D that would be awesome. So did you think it is possible to do it by using metaprogramming, mixin, mixin template, mixin string … ? Thanks for your ideas
Re: Actual lifetime of static array slices?
On Tuesday, 15 November 2022 at 14:05:42 UTC, Siarhei Siamashka wrote: On Tuesday, 15 November 2022 at 13:16:18 UTC, Paul Backus wrote: D's safety model is the same. In `@safe` code, D will reject anything that the compiler cannot say for sure is memory safe. However, unlike in Rust, `@safe` is not the default in D, so you must mark your code as `@safe` manually if you want to benefit from these checks. I specifically asked for Ali's opinion. Because the context is that the compiler couldn't catch a memory safety bug in the code that was annotated as @safe (but without -dip1000) and Ali commented that "the compiler cannot do anything about it in all cases and we wouldn't want it to spend infinite amount of time to try to determine everything". This sounds like he justifies the compiler's failure and accepts this as something normal. The https://dlang.org/spec/memory-safe-d.html page also provides a rather vague statement: "@safe functions have a number of restrictions on what they may do and are intended to disallow operations that may cause memory corruption". Which kinda means that it makes some effort to catch some memory safety bugs. This weasel language isn't very reassuring, compared to a very clear Rust documentation. The goal of `@safe` is to ensure that memory corruption cannot possibly occur in `@safe` code, period--only in `@system` or `@trusted` code. If the documentation isn't clear about this, that's failure of the documentation. However, there are some known issues with `@safe` that require breaking changes to fix, and to make migration easier for existing code, those changes have been hidden behind the `-dip1000` flag. So in practice, if you are using `@safe` without `-dip1000`, you may run into compiler bugs that compromise memory safety. That's what happened in your example. Slicing a stack-allocated static array *shouldn't* be allowed in `@safe` code without `-dip1000`, but the compiler allows it anyway, due to a bug, and the fix for that bug is enabled by the `-dip1000` switch.
