Skip to content
This repository has been archived by the owner on Dec 4, 2022. It is now read-only.

Make "properties" and "operators" first-class concepts #37

Open
timshadel opened this issue Jul 17, 2022 · 2 comments
Open

Make "properties" and "operators" first-class concepts #37

timshadel opened this issue Jul 17, 2022 · 2 comments
Labels
enhancement New feature or request waiting for reply

Comments

@timshadel
Copy link

Is your feature request related to a problem? Please describe.

I really love keeping my getters and setters just below my instance variables. In the Dart Language Tour, it uses the term 'properties' for the logical concept that these getters and setters create. I like sorting the properties (matched get-set pairs) by name and within each pair I place get first, then set.

As I looked into it further, the Dart API docs reminded me that operators should also be grouped out.

Describe the solution you'd like

At the core, I want memberOrdering to reflect each of the concepts in the Dart API docs: constructors, properties, methods, and operators. Plus variables—in source we do need the option to group them.

I propose using new optional items for the memberOrdering—similar to private-other-methods. If the option is used, then that set of items is separated out from their normal area and placed in this new group.

Required Optional
public-constructor public-constructor
named-constructors named-constructors
public-static-variables public-static-variables
public-static-properties
public-instance-variables public-instance-variables
public-instance-properties
public-override-variables public-override-variables
public-override-properties
private-static-variables private-static-variables
private-static-properties
private-instance-variables private-instance-variables
private-instance-properties
public-override-methods public-override-methods
public-other-methods public-other-methods
private-other-methods
operators
build-method build-method

Describe alternatives you've considered

I've thought about flags, but they aren't powerful enough. Each API concept needs to have the full breadth of options that apply to it, so they can be moved in blocks.

Additional context

Big projects tend to have a large number of these properties in certain classes. Keeping them organized is important for all the devs to quickly understand a class.

@gmlewis
Copy link
Owner

gmlewis commented Jul 17, 2022

Thank you for the request, @timshadel.
As I've been working on implementing these changes, I'm trying to figure out how this request will interact with the already-existing groupAndSortGetterMethods variable.
Maybe that option would be turned off if any of these new optional settings are found.
I'm trying to keep the options easy to understand, but as this thing keeps growing, it is getting more challenging.
Still investigating...

@gmlewis
Copy link
Owner

gmlewis commented Jul 17, 2022

@timshadel - I've got my first implementation of this proposal working locally using the standalone Go flutter-stylizer... if you are already familiar with it, then I can push my experimental version to that repo and you can try it out.
https://github.com/gmlewis/go-flutter-stylizer/

Otherwise, I won't push that version but will instead work on porting the Go changes back into the TypeScript changes in the VSCode plugin so that you can try it out first there. (Significant changes like this one are much easier to develop in Go then port to TypeScript as opposed to the other way around.)

Please let me know which way you would prefer to proceed, and I'll try to accommodate your preference.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request waiting for reply
Projects
None yet
Development

No branches or pull requests

2 participants