Ruby is a fully OOP language but doesn't have multiple inheritance either.
Every class is open though (you can add/change methods in them), and you can
create the equivalence of multiple inheritance by using **modules** and
**mixins** where you **include** them in **classes** to extend them.
Please, feel free to ask anything, I'll try my best to answer. Note though,
that that's only my opinion
As for a good read, nothing comes to mind atm. But generally, since you're
asking about OOP in terms of graphics, I would suggest sacrificing OOP, as well
as composition-over-inheritance,
That was really helpful, I'll look into a similar approach and I'll try to
apply these suggestions to other designs I'll have to implement.
I see that the problem is definitely my way of thinking about the project
structure/architecture (which is no surprise given I have a C++ background). I
@Serenitor It's different in many ways:
* also changes semantics of == ("is it actually the same object" instead of
"is this (other) object the same")
* no dynamic dispatch is usable anyway unless {.inheritable.} is applied first
* poorer performance due to dynamic heap allocation (and GC)
> But does that mean I'll have to allocate a new AbstractRenderTarget on the
> heap
Yes. Or you could just return something already cached within the respective
Texture/Window objects to make it high load friendly.
As a side note, your suggested API makes the user believe there's no price for
Just tested the package in Arch Linux, everything works just fine.
Thank you very much for the plugin, I'll be using it from now on.
Before you brought it up we managed to be apolitical. You can discuss this
somewhere else.
> You can't have one side of the issue (ex. Stallman, GitHub, etc) shouting
> political propaganda with a megaphone, but as soon as someone disagrees -
> "OMFG, he brought up politics!? What a vulgar
I don't know the right answer to your problem. However note that a lot of
languages do not support multiple inheritance for a good reason (outside the
scope of this question), so how would you use those? A working pattern for me
is the following: create an interface to your "multi-interface"
Hello everyone. I'm learning Nim but I'm finding it difficult to implement some
OOP software designs I have in mind. I see that Nim is a really flexible
language that doesn't enforce the programmer to a particular programming
paradigm/style (I may be wrong, but that's what I noticed while
Nim is an excellent project but its ecosystem is too damn small. Besides the
core devs what Nim needs is small companies that try nim and release more and
more quality pkgs like yglukhov did with his Reel Valley project.
If you do not have the resources to build something like that do small
There used to be a nim weekly, but don't know what happened to that.
@Ar:
> I think a significant portion of nim users found Nim through Rust. Not sure
> why, but there used to be some sort of competition between the two (or at
> least Nim was more known in the Rust community).
That, if true, is very interesting. I would've thought that Nim's closest
header pragma allows multiple headers in the following way:
proc myProc() {.importc, header: """#include
#include """.}
It is worth noting that header pragma better be avoided as it makes your file
dependent on the header. When function
I suspect Araq suggests using stdlib asyncdispatch instead of libuv.
Hi,
if I want to use the importc pragma, but the header containing the function I
want only works properly, if prefixed by one or more other headers, how do I do
this?
This is the example in the doc:
proc printf(formatstr: cstring) {.header: "", importc: "printf",
varargs.} Run So, what if
> Nim Weekly
This seems like too short period to get enough relevant/interesting stuff, but
(once v1.0 is out) "Nim Monthly" might be a good idea!
> I am going to ignore Rust, D and Nim as they have too few users. Programming
> is a social activity: if nobody can use your code, it does not matter that it
> runs fast.
What the professor really means: his students can't get hired at AAA firms when
trained in languages that aren't in the
Looking thru the Ruby Weekly newsletter
[https://rubyweekly.com](https://rubyweekly.com)/ there was these:
**Top five reasons for Rubyist to use Crystal**
May I suggest that it's probably healthier to leave the politics out of this?
perhaps Araq is talking about SSL wrapping.
looking at devel, it seems that the wrapper of libuv has been delete.
[https://github.com/nim-lang/Nim/tree/devel/lib/wrappers](https://github.com/nim-lang/Nim/tree/devel/lib/wrappers)
20 matches
Mail list logo
