Importing operators
See original GitHub issueFrom the readme:
Note: you need to import these operators from kotlinx.collections.immutable package in order for them to take the precedence over the ones from the standard library.
That makes it very easy to accidentally use the standard operators, which obviously has bad performance implications. Perhaps the operator functions should be instance methods so that the compiler prefers them over the standard plus
/minus
extension functions?
Issue Analytics
- State:
- Created 7 years ago
- Reactions:2
- Comments:7 (3 by maintainers)
Top Results From Across the Web
Import operator - IBM
The import operator reads one or more non-DataStage source files and converts the source data to a destination InfoSphere DataStage data set.
Read more >operator — Standard operators as functions — Python 3.11.1 ...
The operator module exports a set of efficient functions corresponding to the intrinsic operators of Python. For example, operator.add(x, y) is equivalent ...
Read more >Functional interface to built-in operators - PyMOTW
The operator module defines functions that correspond to built-in ... from operator import * a = -1 b = 5 print 'a =',...
Read more >Source code for airflow.operators
Imports operators dynamically while keeping the package API clean, # abstracting the underlying modules. [docs]_operators = { 'bash_operator': ...
Read more >import() - JavaScript - MDN Web Docs - Mozilla
The import() syntax, commonly called dynamic import, is a function-like expression that allows loading an ECMAScript module asynchronously ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Option 3 sounds fair to me, especially since 1 and 2 really don’t seem like feasible solutions. Would all of the current extensions to
Iterable/List/Set/Map
be made available separately and optimized for the corresponding immutable types? Most of my method calls where collections are passed are calls to those, so if they existed, there wouldn’t be too many places where I’d need to addasList()
in my application code.Yes, that is a valid concern.
Unfortunately making them member would clutter the interfaces.
I have another option in mind: if the standard operators know something about immutable collections, they can be specialized in runtime to utilize immutability of those collections.