I'm wading back into the C++ world for a project, and between spending a lot of time with C#, and the new stuff in C++/CX, I'm a bit rusty.
When is it appropriate to use the ref class type introduced in C++/CX?
The built-in reference counting handle seems nice and seems like a good reason to use ref classes wherever possible (ignoring portability concerns). However, I'm unsure if these types add any extra overhead? Or if there's another reason to limit its usage?
Keep in mind that C++/CX is a language extension to make dealing with WinRT types easy. You only have to declare your own ref class when you want to make your type usable by another language, like Javascript or C#. In other words, when you create a WinRT component.
For everything else, which should be the vast majority of your code, use standard C++11 syntax and the normal workhorse C++ standard library classes. Declaring a ref class that you don't expose to other languages just creates unnecessary overhead.
Related
I've just started using Unreal Engine 4, but whenever i choose Object as parent class for my new blueprint, i don't have any constructor (like Construction Script function for Actor)
How can i make a constructor?
I don't want to use Actor becaue the class is storing the equipment data for my character.
Thanks!
I'm afraid it's not possible. Technically Construction Script is not Constructor as you know it from C++. It's somewhat misleading name.
Technically C++ equivalent for Construction Script is AActor::OnConstruction(), not class Constructor.
You must also consider the fact that UObjects are not replicated by default. In future if you would want to make your inventory replicated, you would need to either switch to Actors (which is not that good idea), or write it in C++, where you can explicitly tell, which UObjects should replicate as part of Actor or ActorComponent.
https://github.com/iniside/GameInventorySystemPlugin
Here is Inventory Plugin I'm developing. It's still WIP, but basic functionality is now implemented and it should work with 4.6 version of engine. Right now it's combination of C++ and Blueprint. I also recommend rebuilding it from source if you want to try it out, since default binaries are build against source version of engine.
It should give you nice starting point, to either see how things are done, or just straight to use it.
I found it interesting to read on one of the ways that you can do functional dynamic dispatch in sicp - using a table of type tag + name -> functions that you can fetch from or add to.
I was wondering, is this a typical type dispatch mechanism for a dynamic non OO language?
Also what would be the typical way to monkey path this, using a chaining list of tables(if you don't find it in the first table try next table recursively)? Rebind the table within local scope to a modified copy? ect?
I believe this is a typical type dispatch mechanism, even for non-dynamic non-OO languages, based on this article about the JHC Haskell compiler and how it implements type classes. The implication in the article is that most Haskell compilers implement type classes (a kind of type dispatch) by passing dictionaries. His alternative is direct case analysis, which likely would not be applicable in dynamically typed languages, since you don't know ahead of time what the types of the constituents of your expression will be. On the other hand, this isn't extensible at run-time either.
As for dynamic non-OO languages, I'm not aware of many examples outside Lisp/Scheme. Common Lisp's CLOS makes Lisp a proper OO language and provides dynamic dispatch as well as multiple dispatch (you can add or remove generics and methods at run-time, and they can key off the type of more than just the first parameter). I don't know how this is usually implemented, but I do know that it is usually an add-on facility rather than a built-in facility, which implies it's using functionality available to the would-be monkey-patcher, and also that certain versions have been criticized for their lack of speed (CLISP, I think, but they may have resolved this). Of course, you could implement this type of parallel dispatch mechanism within an OO language as well, and you can probably find plenty of examples of that.
If you were using purely-functional persistent maps or dictionaries, you could certainly implement this faculty without even needing the chain of inherited maps; as you "modify" the map, you get a new map back, but all the existing references to the old map would still be valid and see it as the old version. If you were implementing a language with this facility you could interpret it by putting the type->function map in the Reader monad and wrapping your interpreter in it.
what is the purpose of namespaces ?
and, more important, should they be used as objects in java (things that have data and functions and that try to achieve encapsulation) ? is this idea to far fetched ? :)
or should they be used as packages in java ?
or should they be used more generally as a module system or something ?
Given that you use the Clojure tag, I suppose that you'll be interested in a Clojure-specific answer:
what is the purpose of namespaces ?
Clojure namespaces, Java packages, Haskell / Python / whatever modules... At a very high level, they're all different names for the same basic mechanism whose primary purpose is to prevent name clashes in non-trivial codebases. Of course, each solution has its own little twists and quirks which make sense in the context of a given language and would not make sense outside of it. The rest of this answer will deal with the twists and quirks specific to Clojure.
A Clojure namespace groups Vars, which are containers holding functions (most often), macro functions (functions used by the compiler to generate macroexpansions of appropriate forms, normally defined with defmacro; actually they are just regular Clojure functions, although there is some magic to the way in which they are registered with the compiler) and occasionally various "global parameters" (say, clojure.core/*in* for standard input), Atoms / Refs etc. The protocol facility introduced in Clojure 1.2 has the nice property that protocols are backed by Vars, as are the individual protocol functions; this is key to the way in which protocols present a solution to the expression problem (which is however probably out of the scope of this answer!).
It stands to reason that namespaces should group Vars which are somehow related. In general, creating a namespace is a quick & cheap operation, so it is perfectly fine (and indeed usual) to use a single namespace in early stages of development, then as independent chunks of functionality emerge, factor those out into their own namespaces, rinse & repeat... Only the things which are part of the public API need to be distributed between namespaces up front (or rather: prior to a stable release), since the fact that function such-and-such resides in namespace so-and-so is of course a part of the API.
and, more important, should they be used as objects in java (things that have data and functions and that try to achieve encapsulation) ? is this idea to far fetched ? :)
Normally, the answer is no. You might get a picture not too far from the truth if you approach them as classes with lots of static methods, no instance methods, no public constructors and often no state (though occasionally there may be some "class data members" in the form of Vars holding Atoms / Refs); but arguably it may be more useful not to try to apply Java-ish metaphors to Clojure idioms and to approach a namespace as a group of functions etc. and not "a class holding a group of functions" or some such thing.
There is an important exception to this general rule: namespaces which include :gen-class in their ns form. These are meant precisely to implement a Java class which may later be instantiated, which might have instance methods and per-instance state etc. Note that :gen-class is an interop feature -- pure Clojure code should generally avoid it.
or should they be used as packages in java ?
They serve some of the same purposes packages were designed to serve (as already mentioned above); the analogy, although it's certainly there, is not that useful, however, just because the things which packages group together (Java classes) are not at all like the things which Clojure namespaces group together (Clojure Vars), the various "access levels" (private / package / public in Java, {:private true} or not in Clojure) work very differently etc.
That being said, one has to remember that there is a certain correspondence between namespaces and packages / classes residing in particular packages. A namespace called foo.bar, when compiled, produces a class called bar in the package foo; this means, in particular, that namespace names should contain at least one dot, as so-called single-segment names apparently lead to classes being put in the "default package", leading to all sorts of weirdness. (E.g. I find it impossible to have VisualVM's profiler notice any functions defined in single-segment namespaces.)
Also, deftype / defrecord-created types do not reside in namespaces. A (defrecord Foo [...] ...) form in the file where namespace foo.bar is defined creates a class called Foo in the package foo.bar. To use the type Foo from another namespace, one would have to :import the class Foo from the foo.bar package -- :use / :require would not work, since they pull in Vars from namespaces, which records / types are not.
So, in this particular case, there is a certain correspondence between namespaces and packages which Clojure programmers who wish to take advantage of some of the newer language features need to be aware of. Some find that this gives an "interop flavour" to features which are not otherwise considered to belong in the realm of interop (defrecord / deftype / defprotocol are a good abstraction mechanism even if we forget about their role in achieving platform speed on the JVM) and it is certainly possible that in some future version of Clojure this flavour might be done away with, so that the namespace name / package name correspondence for deftype & Co. can be treated as an implementation detail.
or should they be used more generally as a module system or something ?
They are a module system and this is indeed how they should be used.
A package in Java has its own namespace, which provides a logical grouping of classes. It also helps prevent naming collisions. For example in java you will find java.util.Date and java.sql.Date - two different classes with the same name differentiated by their namespace. If you try an import both into a java file, you will see that it wont compile. At least one version will need to use its explicit namespace.
From a language independant view, namespaces are a way to isolate things (i.e. encapsulate in a sens). It's a more general concept (see xml namespaces for example). You can "create" namespaces in several ways, depending on the language you use: packages, static classes, modules and so on. All of these provides namespaces to the objects/data/functions they contain. This allow to organize the code better, to isolate features, tends for better code reuse and adaptability (as encapsulation)
As stated in the "Zen of Python", "Namespaces are one honking great idea -- let's do more of those !".
Think of them as containers for your classes. As in if you had a helper class for building strings and you wanted it in your business layer you would use a namespace such as MyApp.Business.Helpers. This allows your classes to be contained in sensical locations so when you or some else referencing your code wants to cosume them they can be located easily. For another example if you wanted to consume a SQL connection helper class you would probably use something like:
MyApp.Data.SqlConnectionHelper sqlHelper = new MyApp.Data.SqlConnectionHelper();
In reality you would use a "using" statement so you wouldn't need to fully qualify the namespace just to declare the variable.
Paul
Can anyone tell me why ActionScript 3, a statically typed language, doesn't have generics? Is it too much work? A historical thing? Is there some way to "fake" it that I haven't picked up yet?
Edit: thanks a lot for the answers! The Vector class is basically what I was looking for, and the other information was helpful too.
The new Vector class is a form of generics that Actionscript 3 now supports when compiled for Flash Player 10. They don't support the specification of your own generic classes, yet.
I think Adobe will implement the ES4 standard eventually. It would be nice if they had a competitor who could push them quicker in the right direction. I was expecting a little more from the updates to AS3 when they moved to CS4, but I suppose the revolutionary Vector class will have to suffice.
It looks like they spent a lot of time beefing up the libraries for Flex and AIR, so maybe they'll go back to improving the language support later, but it probably isn't a real priority. Remember, Adobe is in it for the money, not for the feel good of making the sweetest possible language.
I believe it's a historical thing. ActionScript is based on ECMAScript (JavaScript is also based on ECMAScript). ECMAScript is a dynamically typed language, meaning that variables don't have their type declared. Generics are more useful in statically typed languages, wherein the type of variable is declared upfront. In a statically typed language, without generics you're stuck casting all the time from the root object (for example, Object in Java). This is not a problem in ECMAScript, because you can put anything you want into any data structure.
So why didn't ActionScript add generics when they added static typing to ECMAScript? I can't be sure of that, but I think the premise of your question is a bit off - there are generic-esque containers, such as Vector. I might think they'd keep the dynamically-typed containers of ECMAScript (objects and arrays) for backwards-compatibility, but they already broke that between AS2 and AS3, so I'm not sure.
Parameteric types ( the word 'generics' is usually used in ECMAScript for generic methods, rather than the combination of parametric types and runtime polymorphism used in Java ) were proposed as part of ES4, but ES4 fractured and much of the type system proposed for ES ( including the parts implemented in ActionScript ) are not going into the next version. I can't say whether or not Adobe would want to go that way by themselves.
Let's first get proper containers and algorithms in actionscript and then worry about generics...
as3 is not very different from javascript, btw, so your question would kind of apply to JS as well.
Anyone who has programmed with actionscript 3.0 has most certainly noticed its lack of support for private constructors and abstract classes. There are ways to work around these flaws, like throwing errors from methods which should be abstract, but these work arounds are annoying and not very elegant. (Throwing an error from a method that should be abstract is a run-time check, not compile-time, which can lead to a lot of frustration).
I know actionscript 3.0 follows the current ECMAscript standard and this is the reason for its lack of private constructors, but what about abstract classes, are they not in the ECMAscript standard eather?
I guess the more specific question is why does ECMAscript standard not support private constructors? Is it something that can be look forward to in the future?
I have been wondering this for quit sometime, any insight will be much appreciated.
private constructors and abstract classes are not "good OOP elements". they're nice hacks originated in C++. in more dynamic languages they're usually not needed.
abstract classes in particular are totally unneeded, since you don't have to declare the interface in the ancestor to comply with an interface. in fact, you don't even have to inherit from a common ancestor to use some polymorphism.
i'm not saying that AS is better without something like that; rather that you should think in the language you're using, not trying to translate from whatever you're used to.
Neither private constructors nor abstract classes were defined in the old ECMAScript 4 standard on which ActionScript 3 was based. If I remember correctly, the ECMAScript Working Group chose not to implement these more complicated OOP features because there was a certain focus on simplicity and backwards compatibility with older versions of ECMAScript. I interpreted what I heard from them as "we may add these features later, but let's take it slowly". The abstract keyword, for example, is a reserved word, so they have this stuff in mind.
It's worth noting that the working group has chosen to restart the next version of the language with a new focus. This effort is called "Harmony" because two rival sub-groups had very different opinions about where ECMAScript should go in the future. It's a bit of a compromise. Harmony is going to progress much more slowly than the old ES4, and even the class syntax that was already implemented in AS3 will be dropped from the standard initially. In other words, they're going to keep it looking a lot more like today's JavaScript for a while to focus on some other features that are important to the group that was going to branch. This will become ES3.1. Later, classes and some of the more Java-like OOP features will be reconsidered for a new ES4.
What about AS3, though? Basically, Adobe jumped the gun by using a standard that wasn't yet complete, and they got bit by politics. However, Adobe intends to stay involved with the ECMAScript Working Group, and they will likely consider adding features that the working group recommends. That said, AS3 may never be a complete (or fully compatible) implementation of a future ECMAScript. What does that mean? Well, since they're non-standard again, Adobe has the option to add features to ActionScript, even if those features aren't part of a standard. If you feel abstract classes or private constructors are important to you as a developer, request these features in the public Flash Player bug database, or vote for existing feature requests, if they're already present.
I know, this question is really old, but I just stumbled accross and had to amend this:
Constructors are not OO. Objects should be instantiated by factories.
Abstract classes are not OO. Instead one should use interfaces (which AS3 has) and mixins (which AS3 doesn't have).
AS3 is a poor language, but for many more fundamental reasons than these two. AS3 basically is a structured representation of AVM2 bytecode. A 1:1 mapping is easily feasible. And I suppose, it's likely to stay like that, because Adobe appearently has more interest in driving forward platform features, their commercial authoring tools and the flex framework (including mxml).
greetz
back2dos