I've used typescript from some months now and i have not understand the difference from namespaces and modules yet.
I know that before they were named internal and external modules, but with both i can import classes from other files. So what is the real difference?
As it is stated in the TS-handbook
there are 2 kind of modules: "internal" & "external". The code in the internal module is written in Typescript and the "external" is written in Javascript.
In order to align with new ECMAScript 2015's terminology they decided to rename them as follows:
"Internal modules" are now "namespaces".
"External modules" are now simply "modules", as to align with ECMAScript
So:
The way you write your code is different
When using modules the classes are not exposed in the global scope, while using namespaces:
Example:
Let's say you have public namespace sequence NamespaceA.NamespaceB.NamespaceC which exposes public class ClassD.
You can access all of these globally this way:
window.NamespaceA
window.NamespaceA.NamespaceB
window.NamespaceA.NamespaceB.NamespaceC
window.NamespaceA.NamespaceB.NamespaceC.ClassD
without saying window.NamespaceA = NamespaceA
and if you use modules you have to use the "magic" above
Namespaces are TypeScript's way of structuring code when you don't want the outputed Javascript code to use a module loader.
You can find more about namespaces vs modules in the handbook here.
Related
The official site of Typescript get me ask a question,
"Do we need to use namespace or not?".
The following quote explains the 2 things well:
It’s important to note that in TypeScript 1.5, the nomenclature has
changed. “Internal modules” are now “namespaces”. “External modules”
are now simply “modules”, as to align with ECMAScript 2015’s
terminology, (namely that module X { is equivalent to the
now-preferred namespace X {).
So, they suggest that TS team prefer namespace.
Further, it says we should use "namespace" to struct the internal module:
This post outlines the various ways to organize your code using
namespaces (previously “internal modules”) in TypeScript. As we
alluded in our note about terminology, “internal modules” are now
referred to as “namespaces”. Additionally, anywhere the module keyword
was used when declaring an internal module, the namespace keyword can
and should be used instead. This avoids confusing new users by
overloading them with similarly named terms.
The above quote is all from the Namespace section, and yes, it says again, but in a internal secnario.
but in the module section, one paragraph, says that:
Starting with ECMAScript 2015, modules are native part of the
language, and should be supported by all compliant engine
implementations. Thus, for new projects modules would be the
recommended code organization mechanism.
Does it mean that I don't need to bother with namespace, use module all along is the suggested way to develop?
Does it mean that I don't need to bother with namespace, use module all along is the suggested way to develop?
I wouldn't put it exactly that way... here's another paraphrase of what has happened. One upon a time, there were two terms used in Typescript
"external modules" - this was the TS analog to what the JS community called AMD (e.g. RequireJS) or CommonJS (e.g. NodeJS) modules. This was optional, for some people who write browser-based code only, they don't always bother with this, especially if they use globals to communicate across files.
"internal modules" - this is a hierarchical way of organising your variables/functions so that not everything is global. The same pattern exists in JS, it's when people organise their variables into objects/nested objects rather than having them all global.
Along came Ecmascript 2015 (a.k.a. ES6), which added a new formal, standard format that belonged in the "external modules" category. Because of this change, Typescript wanted to change the terminology to match the new Javascript standard (being that it likes to be a superset of Javascript, and tries its best to avoid confusion for users coming from Javascript). Thus, the switch of "external modules" being simplified to just "modules", and "internal modules" being renamed to "namespaces".
The quote you found here:
Starting with ECMAScript 2015, modules are native part of the language, and should be supported by all compliant engine implementations. Thus, for new projects modules would be the recommended code organization mechanism.
Is likely alluding to guidance for users who were not yet using (external) modules. To at least consider using it now. However, support for ES6 modules is still incomplete in that browsers as of May 2016 don't have built-in module loaders. So, you either have to add a polyfill (which handles it at runtime) like RequireJS or SystemJS, or a bundler (like browserify or webpack) that handles it at build time (before you deploy to your website).
So, would you ever use both modules (formerly "external modules") and namespaces? Absolutely - I use them both frequently in my codebases. I use (external) modules to organise my code files.
Namespaces in Typescript are extremely useful. Specifically, I use namespace declaration merging as a typesafe way to add extra properties to function objects themselves (a pattern often used in JS). In addition, while namespaces are a lot like regular object variables, you can hang subtypes (nested interfaces, classes, enums, etc.) off of their names.
Here is an example of a function with a property (very common in NodeJS libs):
function someUsefulFunction() {
// asynchronous version
return ...; // some promise
}
namespace someUsefulFunction {
export function sync() {
// synchronous version
}
}
This allows for consumers to do this common NodeJS pattern:
// asynchronous consumer
someUsefulFunction()
.then(() => {
// ...
});
// synchronous consumer
someUsefulFunction.sync();
Similarly, say you have an API that takes in an options object. If that options type is specific to that API,
function myFunc(options?: myFunc.Options) {
// ...
}
namespace myFunc {
export interface Options {
opt1?: number;
opt2?: boolean;
opt3?: string;
}
}
In that case, you don't have to pollute a larger namespace (say whole module scope) with the type declaration for the options.
Hope this helps!
The project I'm working on, being rather large, consists of one master module, which I'd like to be the API interface, with a number of sub-modules defined within it. This is being done as follows:
<Library.ts>
module Library { }
<Core/Core.ts>
module Library.Core {}
Often the submodules will span a number of files. The problem I'm having is in such situations, one file cannot use non-exported properties defined within the same sub-module, but in another file.
Is there any way I can use these properties, or failing that, any way I can prevent the entirety of a sub-module's exports being exposed within its parent module?
Is there any way I can use these properties, or failing that, any way I can prevent the entirety of a sub-module's exports being exposed within its parent module?
No. You need to export from module Foo for it to be available to module Foo in another file. The same applies to submodules
I am working on some extensions for Rebol 3 (posix/fann/math).
To avoid global namespace pollution, I am exporting the functions with a simple prefix source identifier. For example: POSIX-FORK for fork, or POSIX-NANOSLEEP for nanosleep.
Is there any better approach or official Rebol naming convention?
That's a pretty standard naming convention for Rebol exports, though they should be lowercase in the code of course. The all uppercase thing is just a naming convention when referring to functions in chat clients or web sites that can't show code like this. You generally don't uppercase any words in Rebol code unless they are used for something else.
However, if you want to avoid global namespace pollution, declare your extension module with the options: [private] header. That will make it so the exports of your module are only imported by modules or scripts that request them explicitly with import or the needs header. This especially goes for modules or extensions that export low-level C-like APIs, which are best only imported by the modules that implement the high-level wrappers. It's good to remember that the module part of the extension is a full Rebol module, and it is often best to put your high-level wrapper code there and not export the C-like functions at all, keeping them for internal use.
An additional trick is that when you are exporting constants or enum values, it is best to put them in an object in your module and export the object instead. That way you don't export to the global namespace and you can protect the words from modification.
Another trick is to not export stuff at all and have people import your module using the import function. Unless you mark your module's words as hidden they will still be available even if they're not exported. This is a little inconvenient in most cases though, so it's better to use a private module instead. You can also export your high-level API and not export your low-level API, so the low-level API is available to import if someone wants to use it.
Check here for a more thorough answer about how modules and extensions are used: How are words bound within a Rebol module?
I am creating a COM library with Embarcadero C++ Builder. The designer for the ridl file gives several things you can add to the ridl. I think I understand all of them except for creating new "Modules". I can't find good information for it in the documentation.
What is a "Module" and what would it be used for in COM?
You say you can't find 'good information' in the documentation; what have you found? The RAD Studio help has a section specifically explaining modules, which says:
A module defines a group of functions,
typically a set of DLL entry points.
You define a module by
Specifying a DLL that it represents on the attributes page.
Adding methods and constants using the toolbar or the object list pane
context menu. For each method or
constant, you must then define its
attributes by selecting the it in the
object list pane and setting the
values on the Attributes page.
For module methods, you must assign a
name and DLL entry point using the
attributes page. Declare the
function's parameters and return type
using the parameters page.
For module constants, use the
Attributes page to specify a name,
type, and value.
Note: The Type Library Editor does not generate any declarations or
implementation related to a module.
The specified DLL must be created as a
separate project.
It seems it's specifying methods that exist in an external DLL to whatever module (EXE or DLL) the type library is built into. Exactly what that's used for... is a good question.
The module attribute is described in this MSDN Library page. It permits declaring entrypoints in a DLL. That has little to do with COM, it is just a capability of a type library. You'll find few language development environments that can use them. I think VB6 was one of them. Ymmv.
So I've been programming in C# for the last 6 years or so and now I'm getting my feet wet with VB.net.
The code base I'm working with uses some modules. To me the module looks a lot like a singleton. Only one exists; it can be called anywhere inside the namespace.
Is there something I'm missing here? Does VB not support the normal way a singleton is structured (private constructor/public instance field)?
Modules are not a singleton. It is much more akin to a static class in C#. If you decompile the code you will see they have a very similar structure (modules have an extra attribute).
The major differences between a C# static class and a VB.Net module are ...
Don't have to add Static / Shared qualifiers to methods in a module. They are Shared by default and you cannot change this
If a Module is in an Imported namespace, all of its methods are available without qualification.
Static classes in C# can be generic, modules cannot (although they can have generic members)
If I'm not mistaken, a VB module is the same thing as a static class.