-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorporate Swift Ideas #131
Comments
Assertions Condition must be true, if not return a message immediately and stop execution ALL the way up (if we're in a function, stop all execution. Maybe throw an error?) |
OperationsInstead of the operations we have now, maybe they are global - and if a type supports them then it has overloadable definitions. For example, the "add" (+) operation is defined in a global operations list. Then "add" is defined one or more times on Number. For example, An operation can define if the parameters/return type NEED to be a specific type, otherwise the implementations can add their own. Some operations are available to types if they implement one or more required operations. The dev could add their own operations and implementations. The operation is merely a name that Types can implement. User defined types can also implement these operations so they could do This means if a value passed in is one of X types, and they all have the add operations defined it could perform an add operation without actually knowing the types at compile time. Ideally the OperationExpression saves the exact ID to the runtime implementation, but if it's the operation name then it needs to figure out the types and get the appropriate operation at runtime. Example (common) operations
Numeric operations
Collection operations
Iteration
Mutation
Linear Collection Mutation
Inspecting
Collection Operations
Aggregations
Other
Rules:
|
Control Transfer StatementsCurrently only the return statement halts execution, change the ReturnExpression to a ControlTransferExpression which can do a break, continue, return, throw |
Function TypeWould replace need for Callable ClosureExpression defines the param types and names -> and the expression which returns the result. The closure has access to the context as well as the param types. |
Custom TypesThey can be anything, not just Objects They are added to the Type creators/refs. Similar to Entity, but separate. Entity is still separate, must be object. |
Collection Types
|
ProtocolProtocol is a loose type definition which has operations, props, or methods. A user can pass in any type which meets the protocol. This is referred to as an Interface in other languages. |
The IDE will list all types, some operations are native (defined by runtime) and some are user-defined. |
Inheritance |
GenericsAdd generic types to functions/methods/closure?. In the function definition you can list generic types and their name. They have an expected type, by default it's Any. The generic types are then available in the Parameters of the Function. |
|
To reiterate and refresh my memory: System Types: Any, Boolean, Color, Date, Enum, Function, Generic, List, Many, Map, Not, Null, Number, Object, Optional, Reference, Set, Text, Tuple, Interface Every type can have props, operations, and methods (operations with this = type value) A user can define a type, given a name and type definition. They can add/override operations and methods on top of the system type. Props are determined based on the type definition. A user can define an interface which can have props, operations, and methods (only without definitions) A user can define a new operation ( Is the distinction between operations and methods worth it? Destructure is an expression that gives a type an index/name and that type can determine the destructured type OR say its invalid AND the runtime has an implementation for each type that supports destructuring. |
I like what I see with Swift.
Think about how more swift ideas could be incorporated into Expangine. Document here.
The text was updated successfully, but these errors were encountered: