Re: Is defining get/set methods for every field overkill?
On Sunday, 20 November 2022 at 12:23:39 UTC, Ali Çehreli wrote:
..
Hm. 'private' is about access control.
It's unfortunate that phrase ('private') is used, both
traditionally, and now (and yes, even by me).
A much better, clearer term, would be: 'interaction control',
since that is what the programmer is really trying to achieve
when inserting getters/setters into a class type.
i.e They are creating the specification for an encapulated object
(data, and methods that operate on that data) with the necessary
controls for 'interacting' with it.
On the otherhand, if the programmer is genuinely after 'access'
control, then 'private' just won't do it ;-)
Also, D's 'arbitrary' changes, as mentioned in previous post, do
not further progress the composition problem.
By that I mean, by enabling cooperative interactions within a
module, D has also enabled potentially hazardous interactions as
well, since you cannot enforce a perimeter around a class type
from other code in the module. All code within a module, is
within the bounds of that perimeter, at all times.
i.e. There is no way to enforce the principle of least privilege
within a D module.
On that basis, I might be tempted to agree with you're point of
view -> never, ever, ever, ever, use classes in D.
Re: Seeking in arsd.simpleaudio?
On Sunday, 20 November 2022 at 23:03:49 UTC, Adam D Ruppe wrote: Looking at doing it for mp3 is why I didn't put it in the interface yet... my mp3 code ported to D doesn't have a seek function! This is fixed on my computer now too, just need to check the rest of the bugs. So mp3 support will be coming before long as well. I'll do .wav too later in the week. Not sure about the emulated midi yet, but I'd love them all to implement the same interface, so I'll try. The next arsd tag is gonna have a lot of cool little things.
Re: Is defining get/set methods for every field overkill?
On Monday, 21 November 2022 at 00:29:12 UTC, thebluepandabear wrote: .. not to mention, I'd be out of job if I stopped writing getters/setters ;-) I value your input in this discussion, you have brought some good points. Out of interest, what type of industry-level software are you creating with D? I don't know much companies using D commercially. As someone else mentioned in this thread, there are some 'arbitrary changes' in D, for example, to the traditional concept of the class type, as being a user-defined type for encapsulating data and methods that operate on that data. That is, the module, not the class, is the unit of encapsulation in D. In addition, public is the default visibility in a class in D, which also goes against the traditional concept of using an encapsulated user-defined data type in conjunction with 'information hiding' (or access controls, depending on what terminology you want to use). These decisions no doubt, are design decisions, and not accidental, I presume. These decisions have consequences of course. You should be completely aware of these changes in D, *before* embarking on using classes in D. Some would say those consequences are benefical, while others would reject that proposition, entirely ;-) As such I leave it to the designer(s) of D to better explain their reasoning. These changes by themself rule out the use of D in our environment. "..utility functions operating on data structures. Welcome to 1972!" There are many other reasons also of course, which frankly are unrelated to (and more important) than the above. But otherwise, I find D to be an enjoyable hobby language, particulary for lower-level programming, to both use and explore its capabilities. There are of course some companies using it commercially. But not the company I work for.
Re: Seeking in arsd.simpleaudio?
On Sunday, 20 November 2022 at 23:03:49 UTC, Adam D Ruppe wrote: Here's the patch for ogg, you can download those two files off git master too works great! thanks
Re: Is defining get/set methods for every field overkill?
On Monday, 21 November 2022 at 00:29:12 UTC, thebluepandabear wrote: .. not to mention, I'd be out of job if I stopped writing getters/setters ;-) I value your input in this discussion, you have brought some good points. Out of interest, what type of industry-level software are you creating with D? I don't know much companies using D commercially. I think I may actually have been convinced that writing getters/setters is good practice, I think it's better be safe than sorry because I am writing a library it may be important not to break ABI compatibility in the future if needed, plus I will not need to change the field name if I ever want to add getters/setters.
Re: Is defining get/set methods for every field overkill?
.. not to mention, I'd be out of job if I stopped writing getters/setters ;-) I value your input in this discussion, you have brought some good points. Out of interest, what type of industry-level software are you creating with D? I don't know much companies using D commercially.
Re: Is defining get/set methods for every field overkill?
On Sunday, 20 November 2022 at 12:23:39 UTC, Ali Çehreli wrote: Hm. 'private' is about access control. Encapsulation is something else. Ali "Clearly, encapsulation is not enough." https://www.infoworld.com/article/2075271/encapsulation-is-not-information-hiding.html
Re: Is defining get/set methods for every field overkill?
On Sunday, 20 November 2022 at 23:04:18 UTC, Siarhei Siamashka
wrote:
..
BTW, many software developers and also wikipedia actually agree
with [] () {} ():
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
and.. Autostar C++, Misra C++, Cert C++ ... I could go on and on.
but as you rightly point out, the proof is in the pudding.
some of us actually enjoy going to work each day and creating
great software for our customers...and having to type a
getter/setter doesn't bother us one little bit ;-)
the alternative is just make everything public, and watch our
customer systems fail terribly, with all kinds of awful
consequences...
.. not to mention, I'd be out of job if I stopped writing
getters/setters ;-)
Re: Is defining get/set methods for every field overkill?
On Sunday, 20 November 2022 at 12:23:39 UTC, Ali Çehreli wrote:
On 11/20/22 00:31, [] () {} () wrote:
> If anyone wants to learn more about why encapsulated types
> (classes) have shown to be so useful in my many years of
programming,
Hm. 'private' is about access control. Encapsulation is
something else.
BTW, many software developers and also wikipedia actually agree
with [] () {} ():
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
And this all is getting really silly. The proof is in the
pudding. I mean the existence of really large successful software
is the best evidence of the programming language or coding
technique superiority. C++ has plenty of large successful object
oriented software written using it (Mozilla, Chromium,
LibreOffice, Qt, LLVM, ...). People had a lot of time to try
various C++ features and everyone has their own opinion. Multiple
inheritance isn't very popular, but having private class members
and the ability to easily hide class implementation details is
generally seen as a good and useful feature.
D makes a rather arbitrary change to encapsulation and claims
that this is an improvement. But you can't easily convince
everyone by just making such claims. How it really works in
practice is the only thing that matters.
Re: Seeking in arsd.simpleaudio?
On Sunday, 20 November 2022 at 20:23:28 UTC, TheZipCreator wrote:
and it appears that arsd.simpleaudio doesn't have a seek
function. Is there a way to do this via other means? I want
something like:
Here's the patch for ogg, you can download those two files off
git master too (i can't tag yet since i have a lot of pending
stuff before regression testing but you can copy them into your
current dir or replace the dub cache if you're using that
directly and it will work)
https://github.com/adamdruppe/arsd/commit/1f6ead0a178a8cfbb284d7719fe38863610165e2
It looks like:
auto controller = aot.playOgg("myAudio.ogg");
controller.seek(5.0); // a float that is seconds in the file
Looking at doing it for mp3 is why I didn't put it in the
interface yet... my mp3 code ported to D doesn't have a seek
function! But ogg did, it was just buggy.
Re: Seeking in arsd.simpleaudio?
On Sunday, 20 November 2022 at 22:26:26 UTC, TheZipCreator wrote: I guess in the meantime I'll just use a python script to cut the audio before execution i found the problem the library called seek(-thing) and my seek had a if(x <= 0) return; when it should have been if(x == 0) return. so it wouldn't go backward in the file! i'll add it to the interface and do some more fixes, then i can link you to the new file. should ACTUALLY be closer to 30 mins now but no promises i might still find new bugs yet but it is working in the one test file very well now.
Re: Is defining get/set methods for every field overkill?
On Sunday, 20 November 2022 at 12:23:39 UTC, Ali Çehreli wrote:
On 11/20/22 00:31, [] () {} () wrote:
> Quoted from that video (the one that you agree with):
>
> "I don't ever think that private .. private is like just ..
shouldn't
> even be used."
>
> "so I don't even use classes I just use struct so that
everything is
> always public .. and that in my opinion is the correct
method."
Yes, still agreeing with it.
> If anyone wants to learn more about why encapsulated types
> (classes) have shown to be so useful in my many years of
programming,
Hm. 'private' is about access control. Encapsulation is
something else.
> they can first pay me my fee.
If I could, I would like to pay to have less of that please. :)
Ali
so, as I understand it, your're against the use of private,
against the use of class, and against the use of encapsulation.
we have nothing more to discuss..
.. good luck with your career as a software engineer (but please,
for all our sakes, don't work on any safety-related systems, and
especially not the ones running in my car).
Re: Seeking in arsd.simpleaudio?
On Sunday, 20 November 2022 at 21:57:03 UTC, Adam D Ruppe wrote: On Sunday, 20 November 2022 at 20:34:44 UTC, Adam D Ruppe wrote: i'll get back to you in a lil i went overbudget lol. but yeah the seek function in the underlying lib fails and idk why it is so hard to even trace what error actually happened in these C codebases I can imagine, errors in C are extremely annoying. I guess in the meantime I'll just use a python script to cut the audio before execution
Re: Seeking in arsd.simpleaudio?
On Sunday, 20 November 2022 at 20:34:44 UTC, Adam D Ruppe wrote: i'll get back to you in a lil i went overbudget lol. but yeah the seek function in the underlying lib fails and idk why it is so hard to even trace what error actually happened in these C codebases
Re: Seeking in arsd.simpleaudio?
On Sunday, 20 November 2022 at 20:23:28 UTC, TheZipCreator wrote: so how would you implement this hypothetical `seek` function? (or if you could tell me a different library that already has this functionality that'd be great too) My underlying vorbis lib has it, but haven't added to the simpleaudio interface yet. (Partly cuz i haven't figured it out for the ogg/mp3/wav combo yet) Give me a half hour lemme see if I can do it right now. I'll actually put it on the interface returned by playOgg.. i'll get back to you in a lil
Seeking in arsd.simpleaudio?
I'm currently making a library to do programmatic animation (akin
to [manim](https://www.manim.community/) but for D and a
different style) and for audio arsd.simpleaudio seems like the
only real option (all the others I could find are too low-level
for my taste) but if I want to skip to a specific section of the
video, then I'd need to be able to seek the audio to that
location too, and it appears that arsd.simpleaudio doesn't have a
seek function. Is there a way to do this via other means? I want
something like:
```d
import arsd.simpleaudio, arsd.vorbis;
void main() {
AudioOutputThread aot = AudioOutputThread(true);
aot.playOgg("myAudio.ogg");
import std.datetime;
aot.seek(5.seconds); // or maybe this could be directly in
.playOgg
}
```
so how would you implement this hypothetical `seek` function? (or
if you could tell me a different library that already has this
functionality that'd be great too)
Re: "Little Scheme" and PL Design (Code Critique?)
On Saturday, 19 November 2022 at 19:16:41 UTC, Jack Pope wrote: On Thursday, 17 November 2022 at 22:05:45 UTC, jwatson-CO-edu wrote: [`Atom`](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L66) (unit of data), I throw it on the heap and never bother to delete it. [...] If you wish to automatically de-allocate the oldest atoms, one approach might be to put them in a ring buffer. Its size will affect the relative time needed for deleting and overwriting the oldest elements. You can hard code the size based on experimentation or allow ongoing automatic adjustment based on some formula. I think there are some interesting ring buffer packages in the DUB registry. Thank you, but I do not think the atoms will be freed in order, especially those holding user-defined functions. A ring buffer would be more appropriate for processing items in a stream or for otherwise implementing a queue.
Re: Is defining get/set methods for every field overkill?
On 11/20/22 00:31, [] () {} () wrote:
> Quoted from that video (the one that you agree with):
>
> "I don't ever think that private .. private is like just .. shouldn't
> even be used."
>
> "so I don't even use classes I just use struct so that everything is
> always public .. and that in my opinion is the correct method."
Yes, still agreeing with it.
> If anyone wants to learn more about why encapsulated types
> (classes) have shown to be so useful in my many years of programming,
Hm. 'private' is about access control. Encapsulation is something else.
> they can first pay me my fee.
If I could, I would like to pay to have less of that please. :)
Ali
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 19:40:43 UTC, Ali Çehreli wrote: .. (I fully agree with the posted video.) ... Quoted from that video (the one that you agree with): "I don't ever think that private .. private is like just .. shouldn't even be used." "so I don't even use classes I just use struct so that everything is always public .. and that in my opinion is the correct method." Now, after thoroughly examining that rant, I better understand his agenda. It's hard for me to conceive how a someone who thinks of themself as a 'software engineer' could agree with this. anyho.. If anyone wants to learn more about why encapsulated types (classes) have shown to be so useful in my many years of programming, they can first pay me my fee.
