I tried many ways to implement oop in angularjs, could not find right way to accomplish it. Proper encapsulation, scope and polymorphism as other popular languages.
TypeScript is a nifty language that compiles to human-readable JavaScript and allows a more familiar class syntax for .NET and ActionScript 3 programmers. It's work a look.
Douglas Crockford also has a book called JavaScript: The Good Parts that describes methods for writing OO style code in JS. It's similar to what TypeScript compiles into.
Related
Is anyone working on TypeScript definitions for ExtJS 5? I keep checking DefinitelyTyped but there is no activity:
https://github.com/borisyankov/DefinitelyTyped/tree/master/extjs
I started researching this question in earnest, but found the search results rather unfulfilling.
First of all, here is a small discussion which provides some insight into Sencha's view on TypeScript.
While I couldn't find anything specific to ExtJS 5 (my apologies), I did find this link, which claims to generate TypeScript declaration files using a process that starts with ExtJS documentation. The examples target ExtJS 4.1, but perhaps it could work with ExtJS 5. If so, it would solve your problem. That certainly isn't an answer, but perhaps it's a lead.
As an aside, the conversation referenced above didn't sit right with me. It begins with a seemingly innocent request for Sencha to consider the potential that TypeScript provides for static tooling.
TypeScript
I just spotted TypeScript (http://www.typescriptlang.org/), and it
looks promising. Has anybody had a chance to play around with it yet?
I want to understand if it would be possible to produce a TypeScript
declaration file to declare all the types from the Ext JS and Sencha
Touch frameworks. I'd love to have better static analysis and tool
support for my Sencha development work.
Thanks!
This is the response from a Sencha Senior Forum Manager:
Just another thing to make things ugly [TypeScript]
[EDIT] Regardless of how many times I say this comment was obviously a
personal comment, it's still personal. If you haven't talked to me or
followed me on Twitter or anything, I'm anal about my code and the
syntax that TypeScript (even ES6) is ugly.
That's pretty harsh!
I don't know the forum manager personally, so I am not going to speak to his particular bias against TypeScript. But I do think I can provide some insight into why Sencha representatives might not be rooting for it's success. Perhaps this will help you understand why it might not be a high priority for many people to create a definition file for ExtJS 5.
Please note that I could be wrong and there is an ExtJS 5 definition file out there that just hasn't made it to DefinitelyTyped yet. My search was far from exhaustive.
TypeScript
Here is a simple example of the model of object-oriented programming that TypeScript uses.. Notice that a constructor is a function which returns an instance whose state has potentially been modified or specialized from that of its prototype:
function Mammal() {
//...
}
The constructor's prototype property, which happens to be the prototype of the object returned by the constructor, can then extended with methods and properties (in the ES5 Object.defineProperty sense). The members that are declared on the prototype do not have to be recreated for every instance created by the constructor:
Mammal.prototype = function giveBirth() {
//...
}
In this sense, the constructor is playing the role of a class, and the structure of its prototype property defines the type of object that is created by the constructor. While this pattern is quite verbose in ES3 and ES5, especially when adding in the additional machinery required for inheritance, it is the pattern used by ES6 to define the notion of a class. Therefore, it is the pattern used by the TypeScript compiler to compile a class.
For a more complete treatment of this form of classical object-oriented programming in JavaScript, along with techniques for making classical inheritance more succinct, see this post by Douglas Crockford.
What's noteworthy is that the notion of a type exists only at design time, and is enforced by the TypeScript compiler to help you write sturdier code.
ExtJS
Before TypeScript existed, I had become familiar with the model of classical inheritance employed by Sencha's ExtJS framework. This model provides a means for defining classes and creating instances from their corresponding types using several patterns, including the module pattern and the prototype pattern and the factory pattern. If you are an ExtJS programmer, you'll find these patterns quite familiar, but for reference, please refer to the appropriate sections of Learning JavaScript Design Patterns by Addy Osmani.
As a pure JavaScript developer, this method of classical object-oriented programming is powerful. It is similar in many respects to the model of classical object-oriented programming used by the TypeScript compiler, but with one key difference. In ExtJS, a class and its type are known to the framework, and therefore exist at run time. One of the best things about ExtJS is that it simulates the syntax of creating a class, much like one might do in Java or C#. But it is pale in comparison to the method of specifying a class in TypeScript.
When first introduced, I was so enamoured by the method of class definition employed by ExtJS that I created a library of my own called classical. I was inspired enough to create my own library in order to explore and extend class definition in JavaScript, and to implement it for my own edification. If you click the link above, you'll notice that the project has evolved away from an ExtJS-like class system, and into a base class library for TypeScript.
Why the change?
For starters, TypeScript provided a model of object-oriented programming which not only allowed me to utilize familiar OOP design patterns, but also provided me with a static type system and all the design-time tooling that went along with it. When first discovering TypeScript (version 0.8), my initial reaction was to create a type definition file for classical, which would be a similar (but much simpler) endeavor to creating one for ExtJS. After I had completed this task, the syntax of the resulting library was an utter disaster! I'd like to explore what went wrong, and I'll do so with a simple example from ExtJS.
This code is taken from the discussion mentioned above, and looks like a standard ExtJS class definition:
Ext.define('WebApp.model.RenderableRecord', {
extend: 'Ext.data.Model',
idPropert: 'id',
isRenderableRecord : true,
fields: [
{ name: 'id', type: 'string' },
{ name: 'name', type: 'string' },
{
name: 'renderable',
convert: function (val, model) {return val;}
},
],
renderItems: function (renderer: Function) {
var me = this;
return function (config: Object) {
renderer(me.get('renderable'), config);
}
},
});
Consider the interface that is defined by the prototype above. If static typing in TypeScript was desired, one might create an interface that looks something like this:
module WebApp {
module model {
export interface RenderableRecord extends Ext.data.Model {
idPropert: string;
isRenderableRecord: boolean;
fields: Array<Field>;
renderedItems(renderer: Function);
}
//Assume Ext.data.Model and Field are defined already
//and that the Field interface looks something like this:
export interface Field {
name: string;
type: string;
convert: Function;
}
}
}
Not only would that interface have to be defined alongside the ExtJS definition, but instances would have to have their type specified twice, once as WebApp.model.RenderableRecord (or as a string of the same name when calling Ext.create) and then again by casting it to the appropriate TypeScript type. That's a lot of work to get static typing that is, as a result of the casting, still error-prone!
So what's the problem?
The problem is that there are two type systems in play. One is the design-time type system enforced by the TypeScript compiler. The other is the run-time type system defined by ExtJS. These two type systems are very similar in regard to the way they are implemented, yet they each have a distinct syntax, and therefore have to be specified seperately. Much of the value of a static type system is lost if it two copies of every interface have to be maintained.
Here is a more complete treatment of the hurdles that one must overcome when integrating TypeScript and ExtJS. It also references the GitHub project above. The author concludes that
Unfortunately, TypeScript and ExtJs do not seem to work too well
together.
The bottom line is that ExtJS and TypeScript both define their own type systems, which don't quite play by the same rules. Therefore ExtJS and TypeScript are fundamentally incompatible with each other...
...okay fundamentally is too strong a word, but it takes a lot of work to use the two tools together effectively. So if I was a Senior Forum Manager for Sencha, I might not be rooting for TypeScript either.
Personally, I prefer the ES6 preview, the static type system and the design-time tooling provided by TypeScript. And it's a shame I have to even choose because the two aren't of the same type - one is a framework and the other is a language. And some folks sure do go to great lengths to make them compatible.
ExtJS is a powerful JavaScript framework, which I'm sure has only grown richer in time. But as it is, ExtJS is at it's best when used as a JavaScript framework. Or to quote that same forum manager:
...you can write correct and productive JavaScript without the need of
any compiler like coffeescript or typescript.
ExtJS provides one approach to classical object-oriented inheritance in JavaScript as a framework. TypeScript provides a second approach as a language. If you're interested in TypeScript, take a look at classical. It is far from a professional framework like ExtJS, but it does provide an opinion about what tools might look like when built for TypeScript developers.
I have recently been working on some Typescript definitions for ExtJS, and also contributing to another project that provides a forked Typescript compiler that is more compatible with ExtJS.
See https://github.com/fabioparra/TypeScript
Maybe I answer after a time when the thing is no longer up-to-date, but I created
TypeScript definitions for Ext.JS 5, 6 and 7, because there were a lot of reasons
not to go by ways above:
Patched TypeScript compiller is no longer active. Today TypeScript version is far away from it.
Patched TS compiller is cool, but the TS compiller is too complicated project to maintain
(for Ext.JS classes generating) for me.
The "Premium TypeScript definitions" on https://github.com/thanhptr/extts have
a lot of mistakes and I mean a lot. For example the first call you need
Ext.application({}); is nowhere.
JS Docs in github.com/thanhptr/extts contains HTML syntax, which is not so readable for day work.
Ext.JS TypeScript generator on github.com/zz9pa/extjsTypescript is too simple and not possible
to use for higher Ext.JS versions (5, 6 and 7), but it was the main impulse to create
new Ext.JS TypeScript definitions generator here.
My solution is based on the same principles like this blog post: "Using ExtJs with TypeScript".
But there are a few differences. I thing all differences could be clear from examples:
Example in Ext.JS 5.0.1
Example in Ext.JS 6.0.1 classic
Example in Ext.JS 6.2.0 classic
Example in Ext.JS 7.0.0 classic
The main differences are:
All classes are generated as they are.
All members from 'overrides' files are also generated.
Singleton classes like Ext, Ext.Array etc. are also generated properly.
Classes configurations are placed in *.Cfg interfaces, for example:
Ext.panel.Panel has config interface in Ext.panel.Panel.Cfg.
To extend class, you need more than class config (you need object members like
extend, requires, config, statics or maybe also template methods),
so that's why there are also generated interfaces to have extended class definition:
class extended from Ext.panel.Panel has interface for definition in Ext.panel.Panel.Def.
There are also generated self properties in better way.
There are generated interfaces for listeners/events, for example:
Ext.panel.Panel has interface for events in Ext.panel.Panel.Events.
There are also generated a lot of interfaces for structured method params and more.
There is of course possible to create an application with modern toolkit, but Id didn't make any examples:-).
The solutions supports autocomplete everywhere and Visual Studio code refactoring by CTRL+R, which is very very practical:-)
Please go to find ExtTS - Premium TypeScript type definitions for Sencha Ext JS
https://github.com/thanhptr/extts
Almost every latest versions of ExtJS 4.x, 5.x, 6.x is supported, currently latest version is 6.0.2.437.
Everything you can find from ExtJS API document is in the type definitions with strongly-typed support (such as: Ext.dom.Element, ButtonConfig,..)
There is definitely a room for ExtJS TS definitions
While it's true that TypeScript and ExtJS use incompatible class systems some strategies may be used as a workaround:
Use a patched TS compiler
The ExtJS emitter developed by fabioparra and linked here by Gareth is one possible workaround.
IMHO the main drawback is that it complicates the integration with IDE supporting the TS language. For instance there is no documentation regarding the compatibility of this solution with existing Eclipse TS plugins.
Moreover it is not sure that the development of patch will be maintained for future versions of TypeScript.
Use TS static methods as a factory of ExtJS objects
The idea here is to provide a set of static methods replacing the constructors of ExtJS classes. It becomes thus possible to instantiates ExtJS objects while using the legacy TS compiler.
I have recently delivered this alternative solution named TypExt on github (https://github.com/david-bouyssie/TypExt).
Note that it has to be used in conjunction with proper ExtJS TS definitions (https://github.com/david-bouyssie/TypExt/tree/master/typescripts).
Currently only ExtJS 5.1.1 is supported but I plan to extend the usage of TypExt with other ExtJS versions.
Any suggestion for template base code generator for C / C++ specifically to generate repetitive code generation? (Not UML / MATLAB model based or other advanced stuff). For a newbie in this field any good generic tutorial (not tool based)?
I came across GNU Autogen looks good but looks like it needs a steep learning curve. I would prefer some plug-in for eclipse like IDE, easy to use and most importantly good tutorials.
The basic concept of code generation is simple enough - and people's needs are varied enough - that there are quite a few options out there.
Boost.Preprocessor is a library of functions built on top of the standard C / C++ preprocessor that makes it much easier to use the preprocessor to do code generation. It's not as flexible as other options, and figuring out preprocessor errors can be tricky, but the fact that it uses only standard language features greatly simplifies using it and integrating it into your builds.
If you know Python, there's Cog.
Some of Google's projects use Pump.
There are many general-purpose templating solutions (Python's Genshi, eRuby, etc.). These are often designed for generating HTML and XML but also work for code.
It's also easy enough to hack something together in the scripting language of your choice.
Without knowing more about what your needs are and what tools you're comfortable with, I can't give a more specific recommendation.
I'm not familiar with anything that provides an Eclipse plugin.
If you know Python, then Cog could be considered as light-weight solution: http://www.python.org/about/success/cog/
Look at my answer for a similar question for Java classes using M2T-JET, an eclipse based, lightweight templating generator. JET is language agnostic and you can see from the example that it's fairly easy to use.
I appreciate using Lua for this task, with something like Templet or one of another myriad of Lua-based preprocessors. The benefit of using Lua over something like Python is that you can, if necessary, include the source code to your template processor and a basic Lua installation along with whatever it is you are shipping. You may then add the compilation of Lua and subsequent template files to the build process as usual.
I would advise not using Python-based solutions for one reason: juggling various pythons to satisfy every developer's use of a completely different yet incompatible version is annoying. If you choose to use a language which you can't embed in your trees, you'll want to make sure pre-computed versions are available.
Late to the party but I would recommend Codeworker Its the only tool I found that does everything the above tools do and more. It has the Python Cog like functionality for embedded generation, it has the template based generation like Templet or Pump. And it has the rather useful feature of protected areas so you can customise your code as needed and re-generate.
I have used it for generating all the boiler plate c++ code as well as configuration for projects like SQL, config, javascript etc.
I'm looking for an Ada constructed framework for AI. I think Ada would be perfect for implementing temporal and stochastic paradigms due to its tasking and real-time mechanisms, but did not find anyone who tried to make such a libraries. Actually I did not find strong implementations on other languages too. For C# I found http://www.c-sharpcorner.com/1/56/, and for C++ I found http://mind.sourceforge.net/cpp.html but both did not get much popularity. Maybe java has good AI libraries too, but I do not know. So, do you know an Ada implementation? Would it be useful for more anyone? If you know libraries from other languages, it would be useful to know and compare the implementation models in java, for example. Thanks.
Here's a few resources:
Book, rather old, though (1989): Artificial Intelligence With Ada
Looks like some kind of university student dissertation: MUTANTS: A generic genetic algorithm toolkit for Ada 95
Dmitry Kazakov's AI stuff, mostly fuzzy logic. (Dmitry writes really nice software.)
I once had a school AI project that used the CLIPS AI builder library.
Since I avoid coding in C where I don't have to, I made an Ada Binding to it, which I believe is licensed without restriction. If you want it, have at.
I used it to build an expert system capable of playing a user's opening moves in Empire. All the code is either in Ada, or Clips' expert system specification language.
Here's a potentially useful Java library. I haven't heard of any Ada libraries. Ada is a great language, though.
Here's some genetic stuff.
Can I write programs in JavaFx or Flex with other languages (not ActionScript and JavaFX Script) like in Silverlight?
JavaFX can call Java and thus can call any code that generates Java classes. So you could in theory write code using JRuby or Groovy.
However, I would suggest that is not really how you could should JavaFx (or Flex). Rather you are really using these languages to build great UI using technologies that should be more reliable than AJAX/browser nightmares.
And that their real power comes when you are able to integrate them with back-end data sources (via REST/SOAP) that can be written in whatever language you want.
The question would be easier to answer if we understood why you would want to do this?
For JavaFX the answer is both yes and no, depending on what it is you want to achieve. JavaFX compiles to Java classes and in theory you can call the compiled JavaFX classes from any JVM language that can call Java classes. However, this isn't as simple as it sounds because some of the stunts they are pulling to implement the JavaFX language features make the implemented classes quite complex and the name mangling is not defined and subject to change. Any solution written this way would be very fragile.
However, much of the JavaFX functionality is based on pure Java libraries such as JMC (Java Media Components) for the media support and the scenegraph project (https://scenegraph.dev.java.net/) for the 2D scenegraph. These projects are written in Java and are much easier to call from Java and other JVM based languages.
I don't have any experience of Flex but as far as I know, you are stuck with MXML and ActionScript.
For flex you can only do MXML and Actionscript although there's an option to compile C/C++ code using Alchemy
I was recently diagnosed with a cascading dissociative disorder that causes retrograde amnesia in addition to an existing case of possible anterograde amnesia. Many people have tried to remind me of how great a programmer I was before -- Right now I get the concepts and the idioms, but I want to teach myself whether I know or not. I think I can overcome the amnesia problems in part with it.
My question for you, stackoverflow, is this: I recently found Clojure and it... it feels good to use, even in just copying down the examples from whatever webpage I can find. My goals in learning a functional programming language are to create a simple webserver, an irc AI bot of some variety, and a couchdb-like database system, all of which lightweight and specifically for education. What flaws does Clojure have? Is there a better functional programming language to use right now for education /and/ application?
I think Clojure is a very nice language. If I should point to any defect it is that it's very new, and even though the language seems very mature and production ready, the tools and frameworks around it aren't. So if you are going to make, for instance, a web-app, don't expect to fire three commands and have a "Your first web app is running, now read this documentation to create your models"-page on your browser.
There aren't that many libraries written in Clojure yet either, but that's not a huge problem if you consider that you can use almost anything written in Java.
Haskell currently has a large following and a growing base of libraries and applications. It's also used for education and research. I find it a very nice language to use.
Haskell, Erlang and Clojure are all good choices. I would personally recommend Clojure, you might be able to do some interesting database stuff with the Software Transational Memory system that is part of Clojure.
You list CouchDB in your question, and it's written in Erlang, which is meant to be a pretty engrossing language once you get into it.
I have no personal experience with Clojure, but i really recommend F#. It's quite a powerful language in the style of OCaml. I really like it because it's debugging tools and IDE are second to none, and you can take advantage of practically every library on the (huge) .NET platform.