I'm trying to find the intersection and union between two sequences that have related classes. In order to achieve this I would like to be able to provide a custom equality check to the intersect function. I do not want to override the equals and hashcode function. I would like an intersect function that also takes a function to check for equality.
Is there any clean way to achieve this without writing a custom intersection and union function?
What you're asking is probably not supported by the standard library. It is fairly easy to write your custom intersection/union methods. One other possibility is to wrap your instances like so:
class Wrapper[E](val wrapped: E) {
// Override equals/hashCode here
}
You then compute the union/intersection of Wrapper[E] and then use unionOfWrappers.map(_.wrapped) to get what you wanted. Of course, this will cause many Wrapper instances to be created and garbage collected.
Related
I'd like to compare two instances of the same struct to see if their fields have all the same value. I believe that according to the docs the equality operator wont't work on structs.
What would be the right approach here? Writing a custom equals method for the struct?
I believe your instincts are right, a custom equals method would be best. Other languages allow for for custom comparators so you can do things like create your own == operator for structs. But that’s not a feature atm in Cadence, so an equals methods like you suggested would work in this instance.
It's a rather general purpose question and not specific to any one language. I don't quite understand the point behind passing a function as an argument to another function. I understand that if a function, say, foo1() needs to use some result returned by another function foo2(), why can't the values returned/updated by foo2() be passed to foo1() as is? Or in another scenario, why can't the foo2() be called within foo1() with its results being used therein?
Also what happens under the hood when a foo2() is passed as an argument to foo1()? Is foo2() executed prior to foo1()?
Generally speaking, you pass a function foo2 to a function foo1 in cases where multiple evaluations of foo2 will be necessary - and you perhaps don't know in advance what parameters will be used for each call of foo2, so you couldn't possibly perform the calls yourself in advance.
I think that a sort() function/method on lists might be the best concrete example. Consider a list of People - you might reasonably want to sort them alphabetically by name, or numerically by age, or by geographical distance from a given point, or many other possible orders. It would hardly be practical to include every such ordering as built-in options to sort(): the usual approach taken by languages is to allow the caller to provide a function as a parameter, that defines the ordering between items of the list.
There are many reasons:
Dependency injection: if you pass a method that in production will use a database call, and you use it with different parameters, you could substitute it with some mock when unit testing.
Map, filter, reduce: you could apply the same method to a list of parameters, to map it, filter it or reduce it.
Usually to provide callbacks, or to separate interface from implementation. Look up the following:
1. Dependency Injection,
2. Callbacks,
3. Anonymous Functions (aka Lambdas),
4. PIMPL
etc
Take a look at this book where it is used extensively in developing TDD with C:
https://www.amazon.co.uk/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X
As per my understanding, partial functions are functions that are defined for a subset of input values.
So should I use partial functions for DAO's. For example:
getUserById(userId: Long): User
There is always an input userId which does not exists in db. So can I say it is not defined. And lift it when I call this function.
If yes where do I stop. Should I use partial functions for all methods which are not defined, say for null.
PartialFunction is used when function is undefined for some elements of input data (input data may be Seq etc.)
For your case Option is better choice: it says that return data may be absent:
getUserById(userId:Long):Option[User]
I would avoid using partial functions at all, because scala makes it very easy to call a partial function as though it were a total function. Instead it's better to use a function that returns Option as #Sergey suggests; that way the "partial-ness" is always explicit.
Idiomatic scala does not use null so I wouldn't worry about methods which are not defined for null, but certainly it's worth returning Option for methods which are only defined for some of their possible input values. Better still, though, is to only accept suitable types as input. E.g. if you have a function that's only valid for non-empty lists, it should take (scalaz) NonEmptyList as input rather than List.
I have been reading about methods and functions in Scala. Jim's post and Daniel's complement to it do a good job of explaining what the differences between these are. Here is what I took with me:
functions are objects, methods are not;
as a consequence functions can be passed as argument, but methods can not;
methods can be type-parametrised, functions can not;
methods are faster.
I also understand the difference between def, val and var.
Now I have actually two questions:
Why can't we parametrise the apply method of a function to parametrise the function? And
Why can't the method be called by the function object to run faster? Or the caller of the function be made calling the original method directly?
Looking forward to your answers and many thanks in advance!
1 - Parameterizing functions.
It is theoretically possible for a compiler to parameterize the type of a function; one could add that as a feature. It isn't entirely trivial, though, because functions are contravariant in their argument and covariant in their return value:
trait Function1[+T,-R] { ... }
which means that another function that can take more arguments counts as a subclass (since it can process anything that the superclass can process), and if it produces a smaller set of results, that's okay (since it will also obey the superclass construct that way). But how do you encode
def fn[A](a: A) = a
in that framework? The whole point is that the return type is equal to the type passed in, whatever that type has to be. You'd need
Function1[ ThisCanBeAnything, ThisHasToMatch ]
as your function type. "This can be anything" is well-represented by Any if you want a single type, but then you could return anything as the original type is lost. This isn't to say that there is no way to implement it, but it doesn't fit nicely into the existing framework.
2 - Speed of functions.
This is really simple: a function is the apply method on another object. You have to have that object in order to call its method. This will always be slower (or at least no faster) than calling your own method, since you already have yourself.
As a practical matter, JVMs can do a very good job inlining functions these days; there is often no difference in performance as long as you're mostly using your method or function, not creating the function object over and over. If you're deeply nesting very short loops, you may find yourself creating way too many functions; moving them out into vals outside of the nested loops may save time. But don't bother until you've benchmarked and know that there's a bottleneck there; typically the JVM does the right thing.
Think about the type signature of a function. It explicitly says what types it takes. So then type-parameterizing apply() would be inconsistent.
A function is an object, which must be created, initialized, and then garbage-collected. When apply() is called, it has to grab the function object in addition to the parent.
I have a *-parameter method. I would like to be able to pass a mix of atoms and groups
of atoms into the method. Ideally I would like the groups to be able to hold groups too.
The grammar rule would be:
X = (X | atom)*
The groups need to ordered, but not necessarily of class List.
The motivation is that there are many calls to the *-parameter method and some groups of parameters occur more than once amongst these calls. I would like to be able to store these groups in vals to re-use them.
Why not something like this?
trait GroupOrAtom // or any other nicer name!
class Atom extends GroupOrAtom
class AtomGroup(val atoms: Seq[Atom]) extends GroupOrAtom
def process(elements: GroupOrAtom*) = ...
If you're looking for a more fancy way to do it using union types, try reading Miles Sabin's amazing post on how to implement union types in Scala. This should probably not be your first choice, though, as a solution implementing a common trait like GroupOrAtom is clearer and easier.
Could just passing tuples work for you?
def processor(tokens: Any) = // pattern match on tuples
processor('atom)
processor('atom1, 'atom2)
processor('atom1, ('atom2a, 'atom2b))