Skip to content

introduce struct (lightweight class) #10374

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

Closed
DartBot opened this issue May 1, 2013 · 10 comments
Closed

introduce struct (lightweight class) #10374

DartBot opened this issue May 1, 2013 · 10 comments
Assignees
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-not-planned Closed as we don't intend to take action on the reported issue

Comments

@DartBot
Copy link

DartBot commented May 1, 2013

This issue was originally filed by @tatumizer


Please consider introducing struct (as lightweight class)
Example:
struct ABC { int a; String b; DateTime c; }

should be compiled into

class ABC {
  int a;
  String b;
  DateTime c;
  ABC(this.a, this.b, this.c){}
}

@madsager
Copy link
Contributor

madsager commented May 2, 2013

Added Area-Language, Triaged labels.

@lrhn
Copy link
Member

lrhn commented May 2, 2013

Depending on the order of the fields seems a little "un-dartlike" for me.
I'd prefer at least getting a constructor using named arguments:
  ABC({this.a, this.b, this.c});

Then you can do
  new ABC(a: something, b: other, c: whatnot)
which explains exactly what object you are creating.
Not much shorter than
  new ABC()..a = something..b = other..c = whatnot
though.

@DartBot
Copy link
Author

DartBot commented May 2, 2013

This comment was originally written by @tatumizer


ABC({this.a, this.b, this.c});
I agree with that.
The argument for struct becomes stronger if we consider struct as a value object, and automatically define toString(), hashCode, ==, compareTo and maybe something else based on values. Then it will be good not only for returning "tuples", but for constructing composite keys. [Sorting by composite key is very common in web applications; defining hashCode and others manually is quite error-prone and boring]

@DartBot
Copy link
Author

DartBot commented May 6, 2013

This comment was originally written by @tatumizer


I want to document Lasse's suggestion from mailing list.
Quote:
Maybe make the fields be specified as arguments instead of as fields:
  class Person(String name, int age);
This makes all parameters implicit fields, instead of making all fields implicit constructor parameters.
Then you can specify them as optional or named as well:
  class Person(String name, {int age = 0});
It's just a shorthand for creating a class of (final?) fields and a constructor with the specified initializing parameters.
/End Quote

I think it's a beautiful idea. We follow the syntactic pattern of typedef for function here, instead of inventing new syntax.
Still not sure, maybe "struct" would be a better word in this context (instead of "class") - because this might be a variant of class with a number of autogenerated methods, so we need a general name for this thing, which is not simply "class".
(Issue for discussion).

@gbracha
Copy link
Contributor

gbracha commented Aug 25, 2014

The appetite for syntactic sugar is unbounded, but it comes at a real cost. Every reader of the language, both human and mechanical, has to deal with all this extra stuff. Everyone who learns the language needs to learn each extra construct, and the manuals get bigger and bigger. The tools acquire feature upon feature and grow bloated. It's also a barrier to new tools.

All of this is by way of explaining why keeping the language relatively small is much better than accommodating every potential feature.

In this case, introducing a new construct so that one can avoid typing a constructor is in my judgement the wrong thing to do. It also has an opportunity cost; the cycles spent dealing with these issues come at the expense of dealing with more productive features, or improvements to existing ones. Nothing is free.


Set owner to @gbracha.
Added WontFix label.

@DartBot
Copy link
Author

DartBot commented Aug 26, 2014

This comment was originally written by @tatumizer


I agree with that. The game is not worth the candle.
Main advantage of struct could be: easy serialization, but it can be achieved through other means (e.g. along the lines of minimal_serialization package by Alan).
However, by the same token, yield* is even "more unnecessary" than struct IMO ("Iterable.traverse" method can do the same) :-)
(I have doubts even about plain yield, I think your logic (small is better) applies here, too).

@gbracha
Copy link
Contributor

gbracha commented Aug 26, 2014

I agree that sync* methods are of debatable value. They're there mainly for symmetry, and on the grounds that once you implement all the CPS like machinery for async, they don't add that much cost. But it is a judgement call.

@DartBot DartBot added Type-Defect area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). labels Aug 26, 2014
@kevmoo kevmoo added closed-not-planned Closed as we don't intend to take action on the reported issue and removed resolution-wont_fix labels Mar 1, 2016
@SAGARSURI
Copy link

Is there something similar to inline classes in Dart?

@eernstg
Copy link
Member

eernstg commented Jun 1, 2020

@Asncodes-80
Copy link

Yes I know this issue has closed. But you can use this method at dart 3. Read my answer at stack overflow.

It supports nested types and I think it is more clear next to class type way.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-not-planned Closed as we don't intend to take action on the reported issue
Projects
None yet
Development

No branches or pull requests

8 participants