Remark from editor: Op miss-classified actionscript as javascript.
I am new to Javascript and am confused by the following function declarations in ECMAScript.js2.
public class String extends Object {
...
public native function charAt(pos:Number):String;
public native function charCodeAt(pos:Number):Number;
...
What do ":String" and ":Number" mean? Are these initializer of some sort? How do they work?
Number is the type of the expected parameter and String/Number the type of the return-value's
this does mean:
charAt expects a Number as argument and returns a String
charCodeAt expects a Number as argument and returns a Number
That isn't javascript. as #om-nom-nom found out it's Action-Script
If it's still interesting you though it's not javascript, those are the return values of the functions.
From Wikipedia:
ActionScript is an object-oriented language originally developed by Macromedia Inc. (now owned by Adobe Systems). It is a dialect of ECMAScript (meaning it is a superset of the syntax and semantics of the language more widely known as JavaScript), and is used primarily for the development of websites and software targeting the Adobe Flash Player platform, used on Web pages in the form of embedded SWF files.
...
...
FYI, this isn't javascript syntax (though it may be describing some javascript methods), but the :String and :Number at the end of the function declarations refer to the data type that the function returns.
Related
In this question, I've given examples of package/object that :
implement some functions.
are used to define other functions by only making them availaible to those functions. It means. I don't write a function body but only a spec with "using package_name" or "using package_body" in the end.
I suppose that the way to use my pakcage/object to implement another function is defined somewhere.
I would like to know if there a way to define myself how to use a package/object. I want a way to implement a functions without writing the body everytime but only by writing in the spec that the function is using my package.
What I'm asking for is similar to already implemented function in a interface in java or an extention method in c#.
P.S. : I don't think that title is very clear. I would be glad if someone would propose another title.
I want a way to implement a functions without writing the body everytime but only by writing in the spec that the function is using my package.
You cannot define a function/procedure that references an SQL stored function/procedure like that. If you declare a function or procedure then it must include the signature and the body.
From the documentation:
create_function::=
plsql_function_source ::=
For a standalone function the body is required.
For a call specification, you can reference a function but it will be an external Java method or a C function and NOT another function defined in SQL.
I'm new to clojure and I am trying to figure out what Jepsen does, a software used to check consistency of distributed system.
My questions are:
What does extend-protocol do?
To be more specific, In Jepsen.Generator, what is op in the Protocol.
What does mix mean in the context
Kind Regards
What does extend-protocol do?
A protocol is an abstract thing that looks like an interface in Java. It does nothing, but some other entities may implement it. In Java, you declare a class that implements an interface. In Clojure, you extend a
particular protocol with a custom type declared either with deftype or defrecord calling extend-protocol on it.
When extending a protocol with a type, you need to specify implementation for signatures mentioned in that protocol.
A good example might be JSON serialization. Say, the protocol would look like as follows:
(defprotocol JSON
(to-json [obj]))
If you call (to-json ...) on any value, you'll have an error saying that there is no to-json implementation for that type. You need to extend it:
(extend-protocol JSON
Integer
(to-json [obj] (str obj))
Boolean
(to-json [obj]
(if obj "true" "false")))
Now that, calling (to-json 42) and (to-json false) will work. You may extend that protocol for the rest of types: floats, array, maps and so on.
what is op in the Protocol
Protocols do not have implementations, only signatures. os is a signature of some function that just takes three arguments: [gen test process]. It's up to what should it return. As an example, you may refer the line #46 where its behavior is implemented for the clojure.lang.AFunction type. Since I'm not familiar with jepsen, I cannot say more on that.
What does mix mean in the context
I think its docstring is pretty clear as well as the code is. I takes a collection of gens. If it's empty, the result would be a special Generator instance named void. It's an anonymous type that extends Generator protocol returning just nil when calling op without any computations.
It the gens are not empty, the code returns an instance of Generator type with such op implementation that takes a random gen when executing op.
Hope that will help.
Is there a way to invoke a foreign language API in Rascal? In particular, I've been thinking about the Stanford Core NLP that has a Java API.
Rascal has an excellent Java API. Essentially, a foreign function is defined as an ordinary Rascal function prefixed with the keyword java and an attribute javaClass that defines the class where the function is implemented.
Take the size function on Lists as an example. In Rascal's List module size is defined as follows:
#javaClass{org.rascalmpl.library.Prelude}
public java int size(list[&T] lst);
In the java class org.rascalmpl.library.Prelude, the method size is implemented like this:
public IValue size(IList lst)
{
return values.integer(lst.length());
}
Note that all Rascal values are implemented as (immutable) IValues and that some marshaling is unavoidable.
Final note: interfacing with an NLP library is very interesting (and is actually on our bucket list) but be aware to preserve Rascal's spirit of immutable data and mostly functional solutions. This has to be taken into account when designing the Rascal API for such a library.
I read through the TypeScript Coding guidelines
And I found this statement rather puzzling:
Do not use "I" as a prefix for interface names
I mean something like this wouldn't make a lot of sense without the "I" prefix
class Engine implements IEngine
Am I missing something obvious?
Another thing I didn't quite understand was this:
Classes
For consistency, do not use classes in the core compiler pipeline. Use
function closures instead.
Does that state that I shouldn't use classes at all?
Hope someone can clear it up for me :)
When a team/company ships a framework/compiler/tool-set they already have some experience, set of best practices. They share it as guidelines. Guidelines are recommendations. If you don't like any you can disregard them.
Compiler still will compile your code.
Though when in Rome...
This is my vision why TypeScript team recommends not I-prefixing interfaces.
Reason #1 The times of the Hungarian notation have passed
Main argument from I-prefix-for-interface supporters is that prefixing is helpful for immediately grokking (peeking) whether type is an interface. Statement that prefix is helpful for immediately grokking (peeking) is an appeal to Hungarian notation. I prefix for interface name, C for class, A for abstract class, s for string variable, c for const variable, i for integer variable. I agree that such name decoration can provide you type information without hovering mouse over identifier or navigating to type definition via a hot-key. This tiny benefit is outweighed by Hungarian notation disadvantages and other reasons mentioned below. Hungarian notation is not used in contemporary frameworks. C# has I prefix (and this the only prefix in C#) for interfaces due to historical reasons (COM). In retrospect one of .NET architects (Brad Abrams) thinks it would have been better not using I prefix. TypeScript is COM-legacy-free thereby it has no I-prefix-for-interface rule.
Reason #2 I-prefix violates encapsulation principle
Let's assume you get some black-box. You get some type reference that allows you to interact with that box. You should not care if it is an interface or a class. You just use its interface part. Demanding to know what is it (interface, specific implementation or abstract class) is a violation of encapsulation.
Example: let's assume you need to fix API Design Myth: Interface as Contract in your code e.g. delete ICar interface and use Car base-class instead. Then you need to perform such replacement in all consumers. I-prefix leads to implicit dependency of consumers on black-box implementation details.
Reason #3 Protection from bad naming
Developers are lazy to think properly about names. Naming is one of the Two Hard Things in Computer Science. When a developer needs to extract an interface it is easy to just add the letter I to the class name and you get an interface name. Disallowing I prefix for interfaces forces developers to strain their brains to choose appropriate names for interfaces. Chosen names should be different not only in prefix but emphasize intent difference.
Abstraction case: you should not not define an ICar interface and an associated Car class. Car is an abstraction and it should be the one used for the contract. Implementations should have descriptive, distinctive names e.g. SportsCar, SuvCar, HollowCar.
Good example: WpfeServerAutosuggestManager implements AutosuggestManager, FileBasedAutosuggestManager implements AutosuggestManager.
Bad example: AutosuggestManager implements IAutosuggestManager.
Reason #4 Properly chosen names vaccinate you against API Design Myth: Interface as Contract.
In my practice, I met a lot of people that thoughtlessly duplicated interface part of a class in a separate interface having Car implements ICar naming scheme. Duplicating interface part of a class in separate interface type does not magically convert it into abstraction. You will still get concrete implementation but with duplicated interface part. If your abstraction is not so good, duplicating interface part will not improve it anyhow. Extracting abstraction is hard work.
NOTE: In TS you don't need separate interface for mocking classes or overloading functionality.
Instead of creating a separate interface that describes public members of a class you can use TypeScript utility types. E.g. Required<T> constructs a type consisting of all public members of type T.
export class SecurityPrincipalStub implements Required<SecurityPrincipal> {
public isFeatureEnabled(entitlement: Entitlement): boolean {
return true;
}
public isWidgetEnabled(kind: string): boolean {
return true;
}
public areAdminToolsEnabled(): boolean {
return true;
}
}
If you want to construct a type excluding some public members then you can use combination of Omit and Exclude.
Clarification regarding the link that you reference:
This is the documentation about the style of the code for TypeScript, and not a style guideline for how to implement your project.
If using the I prefix makes sense to you and your team, use it (I do).
If not, maybe the Java style of SomeThing (interface) with SomeThingImpl (implementation) then by all means use that.
I find #stanislav-berkov's a pretty good answer to the OP's question. I would only share my 2 cents adding that, in the end it is up to your Team/Department/Company/Whatever to get to a common understanding and set its own rules/guidelines to follow across.
Sticking to standards and/or conventions, whenever possible and desirable, is a good practice and it keeps things easier to understand. On the other side, I do like to think we are still free to choose the way how we write our code.
Thinking a bit on the emotional side of it, the way we write code, or our coding style, reflects our personality and in some cases even our mood. This is what keeps us humans and not just coding machines following rules. I believe coding can be a craft not just an industrialized process.
I personally quite like the idea of turning a noun into an adjective by adding the -able suffix. It sounds very impropper, but I love it!
interface Walletable {
inPocket:boolean
cash:number
}
export class Wallet implements Walletable {
//...
}
}
The guidelines that are suggested in the Typescript documentation aren't for the people who use typescript but rather for the people who are contributing to the typescript project. If you read the details at the begging of the page it clearly defines who should use that guideline. Here is a link to the guidelines.
Typescript guidelines
In conclusion as a developer you can name you interfaces the way you see fit.
I'm trying out this pattern similar to other answers, but exporting a function that instantiates the concrete class as the interface type, like this:
export interface Engine {
rpm: number;
}
class EngineImpl implements Engine {
constructor() {
this.rpm = 0;
}
}
export const createEngine = (): Engine => new EngineImpl();
In this case the concrete implementation is never exported.
I do like to add a Props suffix.
interface FormProps {
some: string;
}
const Form:VFC<FormProps> = (props) => {
...
}
The type being an interface is an implementation detail. Implementation details should be hidden in API:s. That is why you should avoid I.
You should avoid both prefix and suffix. These are both wrong:
ICar
CarInterface
What you should do is to make a pretty name visible in the API and have a the implemtation detail hidden in the implementation. That is why I propose:
Car - An interface that is exposed in the API.
CarImpl - An implementation of that API, that is hidden from the consumer.
Throughout the examples and explanations of Flux architecture -- Facebook's counterpart to React -- action type names are referenced as enum constants rather than strings. (See examples at http://facebook.github.io/flux/) I am just looking for an articulation of why this is the preferred method.
I do not see a benefit in terms of authoring & convenience, because whether you type constants.actionTypes.UPDATE_DATA (enum constant) or 'UPDATE_DATA' (string), you have to know and type out the exact name. In fact, sometimes the use of non-strings adds complexity -- e.g. you can't as easily make an object with action types as keys and action handlers as values.
Are the benefits in organization, minification, or something else? I'm curious.
You touched on it at the end of your question, but there are a couple benefits. Minification is an obvious one; another is the fact that static analysis tools can more easily find usages and catch errors.
Depending on your flux implementation, they can also help you catch typos. For example, in Fluxxor, if you try to bind a store handler to an action type of undefined, you'll get an exception; that means that passing c.UPDATE_DTA will throw, but passing 'UPDATE_DTA' will not.
Finally, they can help serve as documentation. If all the action types that your application generates are defined centrally as constants, it becomes easier to tell at-a-glance what kinds of operations the system as a whole responds to.
There's an ES6 feature that is available with Babel or Traceur (but not with the JSX transform at this time) that helps create object literals; the syntax is:
var handlers = {
[const.UPDATE_DATA]: this.handleUpdateData,
[const.OTHER_THING]: this.handleOtherThing
};