Recently, there was a talk in my team to use strong types. After a bit of reading different blogs, I am inclined towards avoiding Primitive Obsession and have found below 2 implementations.
NamedType by Jonathan Boccara - https://github.com/joboccara/NamedType
and type_safe by Jonathan Müller - https://github.com/foonathan/type_safe (Coincidentally both being Jonathans).
Since in our codebase, we use something like below, it is easier to adopt using NamedType.
typedef std::uint16_t UNS16;
typedef std::uint32_t UNS32;
Has anyone adapted their codebases to use either of the above implementations?
Related
I know how i can realize a implementation of a class with the policy based design pattern from c++ with Interfaces. I don't know how to do the same with class mixin's.
This would be useful if you want to squeze the last performance out of your code because it is easy inlinable and the "border" of the virtual calls for the interfaces is not there.
I wrote a blog post which might be relevant: Low-overhead components. It discusses using mixins as building blocks for creating flexible, configurable and high-performance components, and the associated caveats.
You mean C++-style policy based design pattern (as explained in Modern C++ Design)? In D you can use static if instead which is simpler.
I'm pretty intrigued by Gambit Scheme, in particular by its wide range of supported platforms, and its ability to put C code right in your Scheme source when needed. That said, it is a Scheme, which has fewer "batteries included" as compared to Common Lisp. Some people like coding lots of things from scratch, (a.k.a. vigorous yak-shaving) but not me!
This brings me to my two questions, geared to people who have used both Gambit and some flavor of Common Lisp:
1) Which effectively has better access to libraries? Scheme has fewer libraries than Common Lisp. However, Gambit Scheme has smoother access to C/C++ code & libraries, which far outnumber Common Lisp's libraries. In your opinion, does the smoothness of Gambit's FFI outweigh its lack of native libraries?
2) How do Scheme's object systems (e.g. TinyCLOS, Meroon) compare to Common Lisp's CLOS? If you found them lacking, what feature(s) did you miss most? Finally, how important is an object system in Lisp/Scheme in the first place? I have heard of entire lisp-based companies (e.g. ITA Software) forgoing CLOS altogether. Are objects really that optional in Lisp/Scheme? I do fear that if Gambit has no good object system, I may miss them (my programming background is purely object-oriented).
Thanks for helping an aspiring convert from C++/Python,
-- Matt
PS: Someone with more than 1500 rep, could you please create a "gambit" tag? :) Thanks Jonas!
Sure Scheme as a whole has fewer libraries in the defined standard, but any given Scheme implementation usually builds on that standard to include more "batteries included" type of functions.
Gambit, for example, uses the Snow package system which will give you access to several support libraries.
Other Schemes fare even better, having access to more (or better) support libraries. Both Racket (with PlaneT) and Chicken (with eggs) immediately come to mind.
That said, the Common Lisp is quite rich also and a large number of interesting and useful libraries are a simple asdf-install away.
As for Scheme object systems, I personally tend to favor Chicken Scheme and have taken to favoring coops. That said, there's absolutely nothing wrong with TinyCLOS. Either would serve well and don't really find anything to be lacking. Though that last statement might have more to do with the fact that I don't tend to rely on a lot of object oriented-isms when writing Scheme. Both systems in my experience tend to surface when I want to write "protocols" and then have a way of specializing on the protocol, if that makes sense.
1) I haven't used Gambit Scheme, so I cannot really tell how smooth the C/C++ integration is. But all Common Lisps I have used have fully functional C FFI:s. So the availability of C libraries is the same. It takes some work to integrate, but I assume this is the case with Gambit Scheme as well. After all, Lisp and C are different languages..? But maybe you have a different experience, I would like to learn more in that case.
You may be interested in Quicklisp, a really good new Common Lisp project - it makes it very easy to install a lot of quality libraries.
2) C++ and Python are designed to use OOP and classes as the typical means of encapsulating and structuring data. CLOS does not have this ambition at all. Instead, it provides generic functions that can be specialized for certain types of arguments - not necessarily classes. Essentially this enables OOP, but in Common Lisp, OOP is a convenient feature rather than something fundamental for getting things done.
I think CLOS is a lot more well-designed and flexible than the C++ object model - TinyCLOS should be no different in that aspect.
I would like to know if maybe there are some good solutions to handling complex types not importable into IDL. My biggest concern is using _m128 vector types for simmed instructions ie. XMVECTOR. __declspec is not recognized by the midl compiler so importing the __m128 data type is out of the question. I looked into using wire_marshal to do this but I think it needs to be aware of the typedef of the __m128 type. If there is a way I can foreword_declare XMVECTOR for use with wire_marshal I haven't the foggiest on how I would do so.
I have thought of hiding the type by encapsulating it which it will already be being that I am encapsulating data types for Reflection. I have played around with a few ideas here including inheriting from both COM and C++ interfaces. Nothing here looked too promising.
A lot of people have told me not to use COM and I honestly have spent a lot of hours not coding and just trying to figure this stuff out. My logic keeps seeing a whole lot of benefits to using COM and the alternatives including MyCOM look just as time consuming and riddled with problems. If this is my biggest problem with using COM should I keep moving foreword or are the solutions going to slow down this application, keeping in mind its reliance on graphical presentation and real time computational modeling? I am looking into doing stuff on scale of rendering farms or clouds or something of the sort... I talk big and I know I am noob so please, not trying to impress just looking to become informed ... I have done a lot of research!
thx,
BekaD:
Leaves a bit of a funny taste in my mouth :\
typedef XMVECTOR* PTR_XMVECTOR;
typedef struct _ARRAY_XMVECTOR {
unsigned int size_array;
[size_is(size_array*SIZE_OF_XMVECTOR)] PTR_XMVECTOR VECTOR_ARRAY;
} ARRAY_XMVECTOR;
typedef [wire_marshal(MARSHAL_AS)] ARRAY_XMVECTOR MY_VECTOR_ARRAY;
I would have edited it in or added it as a comment but probably the closest this thread will come to an answer... probably the obvious one .... sorry for answering my own question :/
Maybe its because I've been coding around two semesters now, but the major stumbling block that I'm having at this point is converting the professor's project description and requirements to actual code. Since I'm currently in Algorithms 101, I basically do a bottom-up process, starting with a blank whiteboard and draw out the object and method interactions, then translate that into classes and code.
But now the prof has tossed interfaces and abstract classes into the mix. Intellectually, I can recognize how they work, but am stubbing my toes figuring out how to use these new tools with the current project (simulating a web server).
In my professors own words, mapping the abstract description to Java code is the real trick. So what steps are best used to go from English (or whatever your language is) to computer code? How do you decide where and when to create an interface, or use an abstract class?
So what steps are best used to go from English (or whatever your language is) to computer code?
Experience is what teaches you how to do this. If it's not coming naturally yet (and don't feel bad if it doesn't, because it takes a long time!), there are some questions you can ask yourself:
What are the main concepts of the system? How are they related to each other? If I was describing this to someone else, what words and phrases would I use? These thoughts will help you decide what classes are useful to think about.
What sorts of behaviors do these things have? Are there natural dependencies between them? (For example, a LineItem isn't relevant or meaningful without the context of an Order, nor is an Engine much use without a Car.) How do the behaviors affect the state of the other objects? Do they communicate with each other, and if so, in what way? These thoughts will help you develop the public interfaces of your classes.
That's just the tip of the iceberg, of course. For more about this thought process in general, see Eric Evans's excellent book, Domain-Driven Design.
How do you decide where and when to create an interface, or use an abstract class?
There's no hard and fast prescriptions; again, experience is the best guide here. That said, there's certainly some rules of thumb you can follow:
If several unrelated or significantly different object types all provide the same kind of functionality, use an interface. For example, if the Steerable interface has a Steer(Vector bearing) method, there may be lots of different things that can be steered: Boats, Airplanes, CargoShips, Cars, et cetera. These are completely unrelated things. But they all share the common interface of being able to be steered.
In general, try to favor an interface instead of an abstract base class. This way you can define a single implementation which implements N interfaces. In the case of Java, you can only have one abstract base class, so you're locked into a particular inheritance hierarchy once you say that a class inherits from another one.
Whenever you don't need implementation from a base class, definitely favor an interface over an abstract base class. This would also be handy if you're operating in a language where inheritance doesn't apply. For example, in C#, you can't have a struct inherit from a base class.
In general...
Read a lot of other people's code. Open source projects are great for that. Respect their licenses though.
You'll never get it perfect. It's an iterative process. Don't be discouraged if you don't get it right.
Practice. Practice. Practice.
Research often. Keep tackling more and more challenging projects / designs. Even if there are easy ones around.
There is no magic bullet, or algorithm for good design.
Nowadays I jump in with a design I believe is decent and work from that.
When the time is right I'll implement understanding the result will have to refactored ( rewritten ) sooner rather than later.
Give this project your best shot, keep an eye out for your mistakes and how things should've been done after you get back your results.
Keep doing this, and you'll be fine.
What you should really do is code from the top-down, not from the bottom-up. Write your main function as clearly and concisely as you can using APIs that you have not yet created as if they already existed. Then, you can implement those APIs in similar fashion, until you have functions that are only a few lines long. If you code from the bottom-up, you will likely create a whole lot of stuff that you don't actually need.
In terms of when to create an interface... pretty much everything should be an interface. When you use APIs that don't yet exist, assume that every concrete class is an implementation of some interface, and use a declared type that is indicative of that interface. Your inheritance should be done solely with interfaces. Only create concrete classes at the very bottom when you are providing an implementation. I would suggest avoiding abstract classes and just using delegation, although abstract classes are also reasonable when two different implementations differ only slightly and have several functions that have a common implementation. For example, if your interface allows one to iterate over elements and also provides a sum function, the sum function is a trivial to implement in terms of the iteration function, so that would be a reasonable use of an abstract class. An alternative would be to use the decorator pattern in that case.
You might also find the Google Techtalk "How to Design a Good API and Why it Matters" to be helpful in this regard. You might also be interested in reading some of my own software design observations.
Also, for the coming future, you can keep in pipeline to read the basics on domain driven design to align yourself to the real world scenarios - it gives a solid foundation for requirements mapping to the real classes.
im reading Practical common Lisp as a result of another question.
I just read chapter 16 and 17 where you can find how LISP manages objects. But after a couple of years of thinking how Java manages objects, i cant really seem to understand how you would implement bigger architectures in LISP using the CLOS.
So i ask you guys for some 20-50 pages reading about CLOS applied to bigger architectures than simple examples. Maybe a couple of blogpost or even experiences!
TY
If you would like to get hold of the book, "Object-Oriented Programming in COMMON LISP" by Sonja E. Keene, Chapter 11 (Developing an Advanced CLOS Program: Streams) contains a non-trivial example with multiple inheritance spanning about 40 pages.
Eight classes are discussed in detail (stream, input-stream, output-stream, bidirectional-stream, character-stream, byte-stream, disk-stream and tape-stream). Concrete classes that a user would be expected to create instances of are then derived using multiple inheritance.
It's more substantial than the bank account example in Practical Common Lisp. You might also find the rest of Keene's book useful in gaining a deeper understanding of CLOS: the whole book is about CLOS.
If you really want to understand CLOS, you can go back and read The Art of the Meta Object Protocol, which provides the basis and the underlying code for Closette, a subset version of CLOS.
Perhaps take a look at the example applications that are walked through in the later chapters. You will see that classes and objects are just another tool in your box. Resist the urge to program Java with Lisp syntax.
Another place to look at is Successful Lisp, chapters 7 and 14 for the basics, and chapters 31 and a part of 3.10 are about packages and handling large projects.
Some Lisp guru (it might have been Paul Graham, but I am not sure) once said that he has not needed CLOS at all yet.
edit: I think that your confusion may come from the fact that in Lisp, you do not use the class system for organizing namespaces. This is done separately; the two do not really have anything to do with each other.
We at Weblocks also use the CLOS heavily, so you might want to browse the source a bit.
Bigger CLOS applications are
1) CAPI from Lispworks
2) cl-http webserver
3) a very large CLOS package is CLIM
4) if you like OpenGenera (that's a Lisp OS using Common Lisp and some predecessor ZetaLisp
5) a smaller package is http://www.cliki.net/mel-base
Regards
Friedrich