I have a method that takes type parameters with an implicit view bounds on them. Can I use the #implicitNotFound annotation to give nicer compiler errors when the method is called with invalid data types?
The documentation for the method is useless and even the source code doesn't help, and all the examples of use online are at the trait or class level.
No, you cannot directly do that. As you’ve noticed, #implicitNotFound annotates traits or classes. You could, however, make a special implicit type just for that method and annotate it if you really wanted to have a custom message.
Related
I have a method where an EStructuralFeature comes in as a parameter. I can get the type of the feature via the method getEType() and get the "real" Java class via the EType's getInstanceClass() method. So far so good. But what if this type is generic, and I want to know its special type? Unfortunately this information is gone due to Java's Type Erasure, but is there a way to achieve this by using EMF's functionality?
EStructuralFeature is an interface extends to ETypedElement
more details here:
[http://download.eclipse.org/modeling/emf/emf/javadoc/2.7.0/org/eclipse/emf/ecore/EStructuralFeature.html]
I'm trying to understand the cake pattern.
I found this gist:
https://gist.github.com/2127745
But I don't understand this syntax:
// Explicit dependency on User Repository
self: UserRepositoryComponent =>
Can someone explain it please?
That's what's known as a self-type annotation. It means that you can assume that the object for the class has the declared type (in this case UserRepositoryComponent, or some subtype), and also (as a bonus) lets you refer to the "this" object at that level as "self", or whatever other name you specify. The self-type annotation is subtly powerful. It expresses a requirement for any implementation of the class (an earlier version of Scala expressed that syntactically as "requires UserRepositoryComponent") but doesn't actually imply a publicly visible type constraint (which would happen if you had said "extends UserRepositoryComponent"). The implementation requirement is enforced at any instantiation of the annotated class, but nowhere else. Self-type annotations are key to the "cake pattern", an encoding of program modules as Scala objects.
It's a self type annotation, explained for example here. If a self-type is given, it is taken as the type of this inside the trait. It lets Trait RealUserServiceComponent, via the self:UserRepositoryComment declaration say it can only be applied to classes that extend the UserRepositoryComment trait.
This is self-type annotation. It's a specification of what can extend your type. Like 'extends', but in the opopposite direction. Knowing that all your subtypes are some implementations of UserRepositoryComponent gives you some additional bonus. Namely you can call all of its methods as they were your own.
Because I can write:
DoubleLinkedList(1,2,3,4)
I expected to find an apply method in the DoubleLinkedList companion object, but I see nothing in the docs linked here. Where is it? Or, why is it not there?
Going up in the hierarchy found it in GenericCompanion. It looks to me like its not being shown may be a Scaladoc bug.
If you read carefully the doc page you mention :
A generic implementation of the CanBuildFrom trait, which forwards all calls to apply(from) to the genericBuilder method of collection from, and which forwards all calls of apply() to the newBuilder method of this factory.
interface test{
foo(boo:string);
}
class coo implements test{
foo(){
}
}
In playGround
this doesn't generate and error although the function signature is not as the interface
says, the expected behavior of interface is to force the signature..
why is this behavior?
Thanks
This is interesting. The TypeScript team are quite clever chaps and they decided to do this deliberately.
The idea is that if your function can operate correctly without being passed an argument, it can safely ignore the argument and satisfy the interface. This means you can substitute your implementation without having to update all of the calling code.
The interface ensures that the argument is passed in all cases where you are consuming the interface - so you get type checking on the callers and it actually doesn't matter that your concrete class doesn't need any parameters.
Interface Function Parameter Not Enforced
I am not satisfied how Interface doesn't enforce the method signature too. I believe the explanations by Fenton are wrong. The real reason is that Typescript is using "duck typing". No erros with less parameters, but you do get errors if you use more parameters.The long answer can be found here Why duck typing is allowed for classes in TypeScript
In the end, Interface can't fit the role of an abstract class that is extended by an other class. I wouldn't recommend to use Interface with classes but instead better use the word "implements" on an actual class, it does the same without the extra Interface class.
Typescript uses structural typing. The implemented function can have fewer parameters than the function declaration in the interface but not more.
Is it possible to create an AOP like interceptor using Scalas new Dynamic Type feature? For example: Would it be possible to create a generic stopwatch interceptor that could be mixed in with arbitrary types to profile my code? Or would I still have to use AspectJ?
I'm pretty sure Dynamic is only used when the object you're selecting on doesn't already have what you're selecting:
From the nightly scaladoc:
Instances x of this trait allow calls x.meth(args) for arbitrary method names meth and argument lists args. If a call is not natively supported by x, it is rewritten to x.invokeDynamic("meth", args)
Note that since the documentation was written, the method has been renamed applyDynamic.
No.
In order for a dynamic object to be supplied as a parameter, it'll need to have the expected type - which means inheriting from the class you want to proxy, or from the appropriate superclass / interface.
As soon as you do this, it'll have the relevant methods statically provided, so applyDynamic would never be considered.
I think your odds are bad. Scala will call applyDynamic only if there is no static match on the method call:
class Slow {
def doStuff = //slow stuff
}
var slow = new Slow with DynamicTimer
slow.doStuff
In the example above, scalac won't call applyDynamic because it statically resolved your call to doStuff. It will only fall through to applyDynamic if the method you are calling matches none of the names of methods on the type.