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

[Request] support subscript `[]`operator overloading #126

Open
Frontear opened this issue Oct 16, 2019 · 5 comments
Open

[Request] support subscript `[]`operator overloading #126

Frontear opened this issue Oct 16, 2019 · 5 comments

Comments

@Frontear
Copy link

@Frontear Frontear commented Oct 16, 2019

Recently operator overloading was added, operations like +, -, *, / amongst other things were added. I noticed however that [] was not a part of this change, and was wondering if it were possible to add.

Basically, it should functions basically how get/set works, for list, map, and other custom objects, accepting the key type and either returning a value or set the value.

List<String> strList = ...;

strList[0]; // List#get(int)
strList[0] = "Hello"; // List#set(int, String)

Map<String, Value> strMap = ...;

strMap["Put"] = new Value(...); // Map#put(String, Value)
strMap["Get"]; // Map#get(String)
@rsmckinney

This comment has been minimized.

Copy link
Member

@rsmckinney rsmckinney commented Oct 16, 2019

@Frontear Several additional operators are under consideration, these include:

  • increment/decrement: ++ and --
  • compound assignment: +=, *=, etc.
  • subscript: [], [] =
    If implemented, a[x] compiles as a.get(x), and a[x] = b compiles as a.set(x, b). Note you could add extension methods to existing classes to satisfy get/set methods e.g., add set(K, V) to Map, which delegates to put(K, V).
@tommyettinger

This comment has been minimized.

Copy link

@tommyettinger tommyettinger commented Oct 17, 2019

Is there a technical/practical reason why all of Java's operators can't be opened up for this? I saw the scientific units of measure and thought about things like square meters and cubic centimeters, which could be represented with an exponent but are fine with m*m or cm*cm*cm. But, sometimes units of measure involve weirder values, like fractal dimension, and that would need a floating-point exponent to be applied to a unit of measure. I could easily be wrong on this scientific usage, but in general being able to represent exponents quickly has long been a weakness of Java and a strength of languages from Ruby (it has a ** operator to exponentiate) to Lua (which until recent versions used ^ for exponentiation; I don't know if that changed with Lua 5.3's added bitwise operations). I wouldn't think changing the meaning of existing operators used on primitive numbers is something that Manifold should enable, but if you have a way in mind to allow user-defined identifiers as binary operators (maybe by implementing both the prefix and postfix bind?), that could be a nice way to avoid some visual overhead. Math.PI toThe Math.E, maybe, if Math.PI ** Math.E or Math.PI ^ Math.E (defined only for float and double, to avoid conflict with XOR) is a no-go. This could definitely get unreadable in a hurry, but I'm very glad you're thinking these features through thoroughly.

@rsmckinney

This comment has been minimized.

Copy link
Member

@rsmckinney rsmckinney commented Oct 17, 2019

@tommyettinger Hi Tommy. Manifold's operator overloading feature is "experimental" which in part means 1) it's not quite finished yet and 2) I have more to learn. One of the things I haven't fully explored is adding new operators, as opposed to overloading existing ones. I briefly considered supporting an exponent operator, but quickly abandoned the idea after realizing I lacked the math chops to implement a solid root() function for Rational numbers, which is necessary to support a fractional exponent. There's probably a reasonable implementation available somewhere. In any case I haven't yet begun connecting the dots in terms of introducing additional operators to javac's codebase via the manifold plugin. I'm sure it's a manageable problem, I just haven't gone down the path yet.

@tommyettinger

This comment has been minimized.

Copy link

@tommyettinger tommyettinger commented Oct 18, 2019

I keep coming back to Manifold and just being shocked by how many seemingly-impossible features have been added so quickly. I'm not currently using it, but a lot of the more recent features seem broadly applicable to all sorts of Java code, and it seems to have gotten more versatile since last I used it. (I stopped using it not because of any fault with Manifold, but because JSON Schema was a poor fit for my data and I was spending more time schema-wrangling than coding.)

@rsmckinney

This comment has been minimized.

Copy link
Member

@rsmckinney rsmckinney commented Oct 18, 2019

@tommyettinger Re seemingly-impossible features. I'd probably be better off if they were impossible. Re JSON Schema, I hear you. After having built a manifold for it I can vouch for JSON Schema being more complicated than it perhaps could be, it's a beast. But it is the de facto standard if you want JSON structures used with other tools. shrug

@rsmckinney rsmckinney changed the title [Request] support array operator overloading [Request] support subscript `[]`operator overloading Oct 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.