Skip to content
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

[WIP] User defined types #122

Open
Binto86 opened this issue Jul 7, 2023 · 0 comments
Open

[WIP] User defined types #122

Binto86 opened this issue Jul 7, 2023 · 0 comments

Comments

@Binto86
Copy link
Contributor

Binto86 commented Jul 7, 2023

There is one issue regarding user-defined types: #41, however, our idea of how the user-defined types should look changed quite a bit. I will summarize here what we came up with and what we are missing.

This issue will be updated with new ideas, things we still need to figure out...

Syntax

State

We would have two types of classes:

  • Braced classes
  • Paren classes

Braced classes

For non-POCO usecases (actual OO design)

  • No constructor provided implicitly
  • Expected to write factory functions
  • Initialization through the initializer syntax
  • Only state is described here, meaning auto-props and fields
class Foo {
    // Gettable and settable auto-prop
    public var X: int32;

    // Get-only auto-prop
    public val Y: string;

    // Mutable field
    internal field var Z: int32;

    // Readonly field
    public field val W: string;
}

Paren-classes

Essentially named tuples, mainly targeting POCOs (exposed data-structures, utility-types)

  • Order of the state is exposed
  • Primary ctor that can be used for initialization
  • Only state is described here, meaning auto-props and fields
class Bar(
    // Gettable and settable auto-prop
    public var X: int32,
    // Get-only auto-prop
    public val Y: string,
    // Mutable field
    internal field var Z: int32,
    // Readonly field
    public field val W: string);

Logic

Any associated behavior of the type is described within a logic block. The logic block can be thought of associating members with a type (not necessarily an instance of the type). Multiple logic blocks can be specified for a type, essentially making this very similar to extension methods.

logic Foo {
    // 'This' keyword is an implicit alias to Foo

    // Static factory
    public func make(): This = This { ... };

    // Member method
    public func toString(this): string = ...;

    // Associated value, AKA. static field, property, ...
    private field var instanceCount: int32;
}

// Implementing a trait, interface or base class
logic IComparable<Bar> for Bar {
    // Only members are allowed here that are present in IComparable<Bar>
}

Member functions

Non-static functions take this parameter while static does not, otherwise, they look the same as free functions.

Properties

Non-static properties take this parameter while static do not.
Properties allow for declaring backing fields inside their scope, which means the backing fields are not visible anywhere outside the prop.
The set accessor has implicit value parameter.

prop Foo(this): int32{
    var backingField = ...;
    get { ... }
    set = ...;
}

// computed props
prop Bar(this): int32 = ...;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant