Re: Advice on OOP in Nim
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. You can use this paradigm with Nim too, as it also provides for **modules**. There's lots of ways to define and do/implement OO paradigms. Below is tutorial info on Ruby's implementation of its OOP paradigm [https://launchschool.com/books/oo_ruby/read/the_object_model](https://launchschool.com/books/oo_ruby/read/the_object_model) [https://www.tutorialspoint.com/ruby/ruby_object_oriented.htm](https://www.tutorialspoint.com/ruby/ruby_object_oriented.htm) Once you figure out the characteristics/features you want to have in your OOP paradigm then you can build it.
Re: Advice on OOP in Nim
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, in favor of DOD (Data Oriented Design). Additional keywords to lookup: ECS (Entity Component System). OOP is really unfriendly to batch processing. DOD turns OOP completely inside out, so to accept this you'll have to forget about OOP completely =). When you start thinking DOD (that will likely take some time), you'll suddenly notice that DOD is a lot more suitable approach for lots of programming problems. It makes your systems not only blazing fast but also makes it easier to reason about your code and your dataflow.
Re: Advice on OOP in Nim
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 guess I'll study a bit more how to avoid "bad OOP" and reason in a "cleaner" way (i.e. like the "prefer composition over inheritance" I read everywhere ). If you happen to have any specific blog post/book/article worth mentioning, that would be amazing. But I'll find stuff myself. I hope I can come back to this thread if I have other questions or I need more advice/help in the future.
Re: Prevent accidental object copies
@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)
* poorer performance due to memory fragmentation
Proof of the first thesis:
type Person = ref object
first, last: string
let person1 = Person(first: "John", last: "Doe")
let person2 = person1 # the very same object
let person3 = Person(first: "John", last: "Doe") # essentially the same
value
echo person1 == person2 # true
echo person1 == person3 # false
I wouldn't be all-overjoyed with these Java-like == semantics...
Re: Advice on OOP in Nim
> 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 switching the rendering context all the time. That could work when you implement deferred rendering (e.g. later, call underlying system functions in a batch per context). But such API will not work for e.g. direct OpenGL rendering, because switching context states is considered to be expensive. nimx lib kinda solves this like this: let myImage = imageWithSize(x, y) myImage.draw: # Context switch here let ctx = getCurrentContext() ctx.drawRect(...) ctx.drawText(...) ... etc # Context switches back
Re: Nim package for ATOM
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.
Re: Wow. It all 'just works'
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 uncivilized brute!!! Fetch my > smelling salts, O goodness, I think I shall faint!" That is not what I'm doing as I'm not the one with the megaphone.
Re: Advice on OOP in Nim
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" object:
type
Texture = ref object ...
AbstractRenderTarget = ref object {.inheritable.} ...
Window = ref object ...
proc setCurrentRenderTarget(t: AbstractRenderTarget)
proc renderTargetWithTexture(t: Texture): AbstractRenderTarget = ...
proc renderTargetWithWindow(w: Window): AbstractRenderTarget = ...
...
var myTexture: Texture = ...
setCurrentRenderTarget(renderTargetWithTexture(myTexture))
You could go a bit further and make renderTargetWithTexture and
renderTargetWithWindow implicit converters, so that setRenderTarget is just:
setRenderTarget(myTexture) # renderTargetWithTexture is called implicitly
Such pattern usually allows for a nice decoupled design, although may be a bit
problematic when you need to work with value types instead of reference types.
Advice on OOP in Nim
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 playing around with it). However I'm having trouble with the lack of multiple inheritance and/or interfaces... I would like to make a concrete example hoping for someone to help me understand what would be an alternative way of implementing something like this in Nim. Let's consider a graphics library (maybe like SFML, strongly object oriented). There are drawable objects (text, rectangles, circles, sprites, etc...) and render targets (a window or a texture - so I can render off-screen to a framebuffer). So the first thing I'll need is some sort of "Drawable" base class/interface and a "RenderTarget" one (I'm strongly referencing SFML here). But then a lot of drawable objects (rectangles, circles, etc...) have in common the fact that they're a shape, and having a "Shape" base class would be pretty useful to recycle a lot of (OpenGL) code used to draw... shapes. But, as far as I can understand, there's not a simple, "native" way of having a Rectangle class inherit from Drawable and Shape. Also, as I mentioned, there are multiple render targets (for example the main window or textures). Even in this case, I would have to define a texture as being both a Drawable and a RenderTarget, but how would be the best way to do that? Please note that I'm not criticizing Nim by any means, in fact I've been using it various times in the last 2 years for various small projects and it's just an amazing language. I'm just asking for some advice/ideas on how to _cleanly_ implement such software architectures, since that has always been my major "trouble" with the language. Also I did various experiments (even with the example above) and I know there are some ways but I have never been satisfied with them (for various reasons). Without listing all the approaches I tried here, I would simply like for someone that is experienced with the language to directly point me out to the "right" way. Or, better said, to a "good" way, since I'm sure there are multiple ones given the flexibility of Nim. Thank you very much in advance, I hope this is not a "dumb" question.
Re: Increasing Nim exposure
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 screencasts, write short blog posts about what you think are cool aspects of Nim and how did it help you to achieve your goal. Other than that we need 1.0 and a continuous development for the C/CPP and JS backends.
Re: Nim for Rubyists
There used to be a nim weekly, but don't know what happened to that.
Re: Wow. It all 'just works'
@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 competitor would be [D](http://forum.dlang.org/thread/mailman.1427.1428691340.3111.digitalmar...@puremagic.com): both are GC by default, both a lot less verbose than Rust, both created by individuals without big .com / .org / .edu sponsorship, nearly tied on most benchmarks (and now even in my package ecosystem license freedom rankings), etc. * * * @dom96 > that is a nice essay. I don't think that ad-hoc rant deserves being called an essay. Your polite tolerance of my rants (especially given that I've never contributed any code) is a great testament to the openness and geniality of the Nim community. > Thank you for taking the time to write it up. To be perfectly honest, GitHub's ten-alarm "Net Neutrality" banners (appearing for weeks on top of every project, file, issue, wiki article, etc) has been a huge blow to me psychologically. Internet freedom is sacred to me, and having calls for slavery injected down my throat in the name of freedom was just too much... And perhaps the worst part is when people don't even see that they did anything divisive or controversial... I've resisted bringing up this issue as a separate thread, but I guess I've jumped on too eagerly when I thought that @KevinGolding brought up the issue of left-wing political bias first. I now feel morally obligated to disassociate myself from GitHub - which is near darn impossible. A huge and growing fraction of the free software ecosystem is married to GitHub, _including Nim and the vast majority of its modules and tooling..._ > Sadly I cannot agree with some of your points, in particular regarding net > neutrality. I've not made any detailed arguments against "Net Neutrality" in my previous post. I've just said that it was a recent and particularly egregious "example of left-wing political hijacking" of free software communities - and one that _most directly involves Nim._ It would have been great if GitHub used such a banner to raise funds for hurricane victims, for example, but what they did was very very different - and perhaps some people don't even see this. I'll make more detailed arguments against "Net Neutrality" in this post, but only to illustrate that there are two sides to this issue. I don't expect anybody to ever change their political opinions, but what is most insulting is how **the left no longer even sees anyone who disagrees with them as human**. "Everyone must agree that Net Neutrality == freedom, no two ways about it, and anyone who disagrees is a bot for [soulless flat-earther corporate shills](http://dailysignal.com/2018/01/10/death-threats-fcc-chairman-unprecedented-must-stop/)"... > Many ISPs have a monopoly, especially in the US. So letting them go on to do > whatever they please, unregulated will be a nightmare. All claims of a "natural monopoly" are a conjecture that becomes a self-fulfilling prophecy, stifling technological innovations that would enable competition, but it is especially ridiculous in regards to the Internet. The Internet is a network, not a "monopoly". There are two different visions of Internet freedom: * A socialist vision of Internet freedom, based on faith that Mommy Government will make the Internet free. It pours opium on the government-created toothache of cable "monopolies", dulling the pain and enabling the illness to continue. The price of this opium is that everyone must trust the government to always put [its own interests](https://en.wikipedia.org/wiki/Niccolò_Machiavelli) aside. All governments everywhere are magically benevolent, and they would never censor or discriminate against anyone, ever. * A capitalist vision of Internet freedom, based on free market competition (which is how networks actually work). This vision would have avoided the cable monopolies in the first place, and encouraged a lot more and faster technological innovation with wireless (cellular, satellite, municipal wifi, drone wifi, mesh networking, etc) and locally owned (["last mile"](https://en.wikipedia.org/wiki/Last_mile), neighborhood cache, IPFS, etc) connectivity technologies. You have a choice between dozens of ISPs, and you can connect to several at the same time, adding or dropping subscriptions as you see fit (ex. based on connection speed). Ideally you also use independent VPN(s), so your ISP(s) can't even tell what you do online much less discriminate. Maybe most people prefer the former, but people who prefer the latter should still be treated with respect. I just hope that you understand that what GitHub did has crossed a serious line. As far as I'm concerned it was an act of war, in the propaganda sense of the term. * * *
Re: importc: multiple headers?
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 or struct ABI is well defined, you can
easily get away with just importc pragma.
Re: Is anyone using the libuv wrappers?
I suspect Araq suggests using stdlib asyncdispatch instead of libuv.
importc: multiple headers?
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 "" needed to be imported before ""?
Re: Nim for Rubyists
> 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!
Re: Increasing Nim exposure
> 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 top 20.
Nim for Rubyists
Looking thru the Ruby Weekly newsletter [https://rubyweekly.com](https://rubyweekly.com)/ there was these: **Top five reasons for Rubyist to use Crystal** [https://crystal-lang.org/2018/01/08/top-5-reasons-for-ruby-ists-to-use-crystal.html?utm_source=rubyweekly_medium=email](https://crystal-lang.org/2018/01/08/top-5-reasons-for-ruby-ists-to-use-crystal.html?utm_source=rubyweekly_medium=email) and then the Rustacean foray for mindshare **Rust for Rubyists**: [https://matthias-endler.de/2017/rust-for-rubyists/?utm_source=rubyweekly_medium=email](https://matthias-endler.de/2017/rust-for-rubyists/?utm_source=rubyweekly_medium=email) The article which really spiked my interest in Nim (coming from Ruby) is from July 2017 below: **Nim for the discerning Rubyist** [http://www.bootstrap.me.uk/bootstrapped-blog/nim-for-the-discerning-rubyist](http://www.bootstrap.me.uk/bootstrapped-blog/nim-for-the-discerning-rubyist) It would be really nice to have more of these articles to show Rubyist how to use Nim to their advantage. It would also be really nice to have a **Nim Weekly** newsletter too. I have some things I could possibly contribute. Something to work toward.
Re: Wow. It all 'just works'
May I suggest that it's probably healthier to leave the politics out of this?
Re: Is anyone using the libuv wrappers?
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)
