Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On 7/17/21 8:52 PM, someone wrote: > I am a self-taught programmer Same here. > well before college Not here because I had access to a Sinclair Spectrum only in 1985. :/ > I have a degree in electronics engineering Same here. > one of the things that I felt in love with when I was first exposed to was OOP; with all its pros and cons I learned it with C++. Then I realized that it wasn't much used in D. The following two presentations made me leave it completely behind unless a simple class hierarchy is really necessary. 1) Our friend Luís Marques presented the following at one of our local meetups. (He was distant. :) ) http://files.meetup.com/18234529/luis_marques_anemic_domain_models.pdf That presentation concludes that anemic domain models are better than rich design models. An interesting question from the presentation to all OOP people is "How might you design a program that lets people play Monopoly with each other over the internet?" Very eye opening! 2) Our "open methods" friend Jean-Louis Leroy concludes that OOP took a wrong path in programming language history: https://dconf.org/2018/talks/leroy.html It starts with the "expression problem" (which is *not* about "expressions"). > it was on one of my first jobs as a developer at a financial institution which by the time back in the early 90s was > using a database manager called FoxPro Same here! :) I learned and programmed in FoxPro for my first job in the US, in Sausalito, CA in 1994. I was maintaining and improving an order entry, invoicing, inventory, etc. system. I had not even heard about OOP back then to know whether FoxPro was good at it. :) > It was with this tool that I learned primarily to encapsulate everything > -and it payed off; code quality using OOP was far superior. Ah! OOP carries many meanings with it. Yes, encapsulation is important, which I take less advantage of as I gain experience. :) (I am going backward!) But I left "everything is an object" mantra way back in my programming history. Pffft! > C++ came afterward with all its complexity and 50% of the guys loving > it I've been one of those. > I respect it, it is powerful, the > problem with C++ is that anyone writing code with it feels the need to > show you how big has his ... That. I've been there myself and I am pretty sure most of the brain power that is attracted to C++ is there for the same reason. I asked a C++ speaker why he was interested in C++ instead of one of the more modern languages and he said "because it is hard". > unless you have some guidelines cast in stone at company level More than 400 rules in Core Guidelines alone... Add to that more hundreds of MISRA, AUTOSAR, etc. standards. How can one expect programmers to observe all of those rules? And only some of the guidelines are machine-checkable. Anyway... Back to D... :) Ali
Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On Sunday, 18 July 2021 at 01:49:11 UTC, Brian Tiffin wrote: It's our best hope. Self taught programming is scary. School taught programming is scary. Corporate taught programming is scary. *Practice makes perfect? No, practice makes permanent.* The sanest path forward for the profession is Peer taught programming, in public. I am a self-taught programmer well before college, furthermore, I am *almost* a self-taught guy in everything that interests me (albeit the fact that I have a degree in electronics engineering), but I am *not*, in *any way*, ashamed to ask anything no matter the issue, I have no pride when I am asking questions, I am not ashamed to answer no when I don't have the answer, I want to learn, and to teach whenever I feel I have and edge on something. That being said, one of the things that I felt in love with when I was first exposed to was OOP; with all its pros and cons. OOP made me a far better programmer than I was before. And it was not in college nor anywhere near to, it was on one of my first jobs as a developer at a financial institution which by the time back in the early 90s was using a database manager called FoxPro wich evolved to Visual FoxPro by the time Microsoft bought it and it was fully OOP from top to bottom and was far ahead of similar tools of the era, so far ahead in the language and flexibility and speed that a few years after it was released Microsoft killed it because a lot of companies were doing serious business with it while *not buying* Microsoft's star-database, SQL Server, which obviously was far far expensive. It was with this tool that I learned primarily to encapsulate everything -and it payed off; code quality using OOP was far superior. These were my humble origins to OOP far away from things like LISP and what-not that I didn't know they even existed. C++ came afterward with all its complexity and 50% of the guys loving it and the other 50% hating it with passion. I don't know of any other language so divisive than C++. And no, I don't love it nor hate it, I respect it, it is powerful, the problem with C++ is that anyone writing code with it feels the need to show you how big has his ... and you came across constructions that seem complex puzzles; so, in practice, unless you have some guidelines cast in stone at company level, you end fighting the language, or more precisely, the ones coding with the language.
Re: interface function member declarations needing parameter attributes ?
On Saturday, 17 July 2021 at 21:01:00 UTC, Adam Ruppe wrote: From the interface perspective: are these signatures identical or not ? No, they are very different. This helped me solve an issue that I carried since a few days ago: I have an interface with function members *not* being declared @safe (at first glance it seemed irrelevant to me just to mark @safe a declaration and not an actual implementation). I also have former @safe member functions in classes implementing this interface that at some point I did have to take out the @safe declarations because the compiler didn't like them anymore due to some change I made which I didn't link to them, and from the on I did not quite understand why it was complaining since everything seemed perfect to me (as usual ha). Now that I marked the ones in the interface @safe I can also mark the ones implementing them @safe again and now everything is @safe and working properly. Another day, another lesson learned.
Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On 7/17/21 6:49 PM, Brian Tiffin wrote: > *Practice makes perfect? No, practice makes permanent.* One reference for that quote is "Classical Guitar Pedagogy" by Anthony Glise, Chapter Nine--Practicing. ;) Ali
Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On Sunday, 18 July 2021 at 00:00:01 UTC, zjh wrote: On Saturday, 17 July 2021 at 22:40:35 UTC, someone wrote: On Saturday, 17 July 2021 at 21:46:38 UTC, Jack Applegame wrote: This must be `Forum Oriented Programming`. It's our best hope. Self taught programming is scary. School taught programming is scary. Corporate taught programming is scary. *Practice makes perfect? No, practice makes permanent.* The sanest path forward for the profession is Peer taught programming, in public.
Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On Saturday, 17 July 2021 at 22:40:35 UTC, someone wrote: On Saturday, 17 July 2021 at 21:46:38 UTC, Jack Applegame wrote: This must be `Forum Oriented Programming`.
Re: interface function member declarations needing parameter attributes ?
On Saturday, 17 July 2021 at 22:48:00 UTC, Adam D Ruppe wrote:
On Saturday, 17 July 2021 at 22:43:15 UTC, someone wrote:
So the lesson learned is that interfaces can also mandate
member function's parameter attributes then ... right ?
A subclass must accept anything the parent class can, but it
can also make it stricter if you want.
class Base {
void foo(Object o) {}
}
class Derived : Base {
override void foo(const Object o) {}
}
That's legal because const also accepts mutable. Derived is
stricter than Base which is permitted. But the other way around:
class Base {
void foo(const Object o) {}
}
class Derived : Base {
override void foo(Object o) {}
}
is NOT allowed because the mutable thing in derived cannot be
passed back to the base interface implicitly.
Perfectly clear; thanks Adam :) !
Re: interface function member declarations needing parameter attributes ?
On Saturday, 17 July 2021 at 22:43:15 UTC, someone wrote:
So the lesson learned is that interfaces can also mandate
member function's parameter attributes then ... right ?
A subclass must accept anything the parent class can, but it can
also make it stricter if you want.
class Base {
void foo(Object o) {}
}
class Derived : Base {
override void foo(const Object o) {}
}
That's legal because const also accepts mutable. Derived is
stricter than Base which is permitted. But the other way around:
class Base {
void foo(const Object o) {}
}
class Derived : Base {
override void foo(Object o) {}
}
is NOT allowed because the mutable thing in derived cannot be
passed back to the base interface implicitly.
Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On Saturday, 17 July 2021 at 21:46:38 UTC, Jack Applegame wrote: Just remove `ref`, because in D clasess themselves are references. All refs are goners now; thanks :) !
Re: interface function member declarations needing parameter attributes ?
On Saturday, 17 July 2021 at 21:01:00 UTC, Adam Ruppe wrote: No, they are very different. So the lesson learned is that interfaces can also mandate member function's parameter attributes then ... right ? But you also don't gain much from const here and that ref is probably actively harmful so i wouldn't use them here. ref is gone.
Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On Saturday, 17 July 2021 at 21:02:38 UTC, Adam Ruppe wrote: Why are you using ref here at all? Muscle memory I suppose; objects need to be passed by reference, these are the things I'll need to be re-wired to in D. You probably shouldn't be using it. But if it is legitimately needed you can do a pointer instead of ref. No. Nothing special at all here.
Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On Saturday, 17 July 2021 at 20:49:58 UTC, someone wrote:
The following gives me a compiler error when I add the second
parameter:
is not an lvalue and cannot be modified
```d
public bool add(
ref classTickerID robjTickerID,
ref classExchanges robjExchanges = null /// needing this
optional
) {
}
```
If I take out the null then the parameter is assumed mandatory
of course.
Just remove `ref`, because in D clasess themselves are references.
Re: interface function member declarations needing parameter attributes ?
On Saturday, 17 July 2021 at 20:42:06 UTC, someone wrote: From the interface perspective: are these signatures identical or not ? No, they are very different. But you also don't gain much from const here and that ref is probably actively harmful so i wouldn't use them here.
Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On Saturday, 17 July 2021 at 20:49:58 UTC, someone wrote: ref classTickerID robjTickerID Why are you using ref here at all? You probably shouldn't be using it. But if it is legitimately needed you can do a pointer instead of ref.
function parameters: is it possible to pass byref ... while being optional at the same time ?
The following gives me a compiler error when I add the second
parameter:
is not an lvalue and cannot be modified
```d
public bool add(
ref classTickerID robjTickerID,
ref classExchanges robjExchanges = null /// needing this
optional
) {
}
```
If I take out the null then the parameter is assumed mandatory of
course.
interface function member declarations needing parameter attributes ?
```d
public interface intefaceWhatever {
public bool doSomething(
dstring lstrID,
classX robjX
);
}
```
vs
```d
public interface intefaceWhatever {
public bool doSomething(
const dstring lstrID,
ref classX robjX
);
}
```
From the interface perspective: are these signatures identical or
not ?
Is the latter needed ... or if not, makes sense as best practice ?
Re: Creating immutable arrays in @safe code
On 17.07.21 14:56, Dennis wrote:
On Saturday, 17 July 2021 at 12:05:44 UTC, ag0aep6g wrote:
Hm, as far as I understand, "strongly pure" doesn't require
`immutable` parameters. `const` should be enough. The spec says: "A
strongly pure function has no parameters with mutable indirections" [1].
I just took the description from the source code:
```D
enum PURE : ubyte
{
impure = 0, // not pure at all
fwdref = 1, // it's pure, but not known which level yet
weak = 2, // no mutable globals are read or written
const_ = 3, // parameters are values or const
strong = 4, // parameters are values or immutable
}
```
That looks off to me. Unless DMD has some secret knowledge about a
shortcoming in the established definition of "strongly pure", I think
those enum values are badly named.
At a glance, the only meaningful use of `PURE.strong` seems to be in
dcast.d, introduced by the PR you linked. Changing that to `PURE.const_`
doesn't break any tests for me. So I'm inclined to believe that
`PURE.strong` is nonsense, and that `PURE.const_` already means
"strongly pure".
However, changing that instance doesn't fix the issue. Apparently, DMD
doesn't even recognize
int[] array(const int[] input) pure { ... }
as `PURE.const_`.
I don't know whether the spec or code is correct.
When it comes to purity, another piece in the puzzle is David
Nadlinger's article:
https://klickverbot.at/blog/2012/05/purity-in-d/
There, a function with a `const int[]` parameter is described as
"strongly pure".
As far as I can remember, when DMD and that article disagreed in the
past, DMD was wrong.
[...]
Yup, [remember
this](https://github.com/dlang/dmd/pull/8035#discussion_r174771516)?
Hehe, I knew I had complained about it before.
It's doubly bad: (1) We're missing out on bug fixes, because they're
hidden behind `-preview=dip1000` for no reason. (2) When
`-preview=dip1000` ever becomes the default, code will break that
doesn't even use the features of DIP 1000.
Re: Creating immutable arrays in @safe code
On 18/07/2021 12:56 AM, Dennis wrote: I don't know whether the spec or code is correct. Unless otherwise specified, the code is authoritative.
Re: Creating immutable arrays in @safe code
On Saturday, 17 July 2021 at 12:05:44 UTC, ag0aep6g wrote:
Hm, as far as I understand, "strongly pure" doesn't require
`immutable` parameters. `const` should be enough. The spec
says: "A strongly pure function has no parameters with mutable
indirections" [1].
I just took the description from the source code:
```D
enum PURE : ubyte
{
impure = 0,// not pure at all
fwdref = 1,// it's pure, but not known which level
yet
weak= 2,// no mutable globals are read or written
const_ = 3,// parameters are values or const
strong = 4,// parameters are values or immutable
}
```
I don't know whether the spec or code is correct.
Also, conflating other issues with DIP1000 is such an obviously
terrible idea.
Yup, [remember
this](https://github.com/dlang/dmd/pull/8035#discussion_r174771516)?
Re: Creating immutable arrays in @safe code
On 17.07.21 13:05, Dennis wrote: There used to be a complex `isReturnIsolated` check, but the [fix for issue 15660](https://github.com/dlang/dmd/pull/8048) reduced it to a check 'is the function strongly `pure`' which means 'parameters are values or immutable'. To reduce code breakage, the 'strong pure' requirement is only needed with -dip1000, which is why your example doesn't work with it. Hm, as far as I understand, "strongly pure" doesn't require `immutable` parameters. `const` should be enough. The spec says: "A strongly pure function has no parameters with mutable indirections" [1]. Seems to me that the fix is buggy. Also, conflating other issues with DIP1000 is such an obviously terrible idea. [1] https://dlang.org/spec/function.html#pure-functions
Re: Creating immutable arrays in @safe code
On Saturday, 17 July 2021 at 05:44:24 UTC, ag0aep6g wrote: I tried doing that, but `-preview=dip1000` causes trouble. This fails: (...) I'm not sure what's going on. I'm not completely caught up, but from what I see, pure and immutable have a history of issues: [Issue 11503 - Type system breaking caused by implicit conversion for the value returned from pure function](https://issues.dlang.org/show_bug.cgi?id=11503) [Issue 11909 - Struct members and static arrays break pure function escape analysis (immutability violation)](https://issues.dlang.org/show_bug.cgi?id=11909) [Issue 15660 - break immutable with pure function and mutable reference params](https://issues.dlang.org/show_bug.cgi?id=15660) There used to be a complex `isReturnIsolated` check, but the [fix for issue 15660](https://github.com/dlang/dmd/pull/8048) reduced it to a check 'is the function strongly `pure`' which means 'parameters are values or immutable'. To reduce code breakage, the 'strong pure' requirement is only needed with -dip1000, which is why your example doesn't work with it.
