Can anyone help me understand this piece of code?
#immutable
abstract class User with _$User {
const factory User(String name, int age) = _User;
}
The syntax I particularly want to understand is the benefit for the class to mixin itself apparently and what the prefix _$ means in the declaration.
From what I see you most likely dealing with class that will have more code generated using code generator.
Class User does not mixin itself. It mixins class $User. Class $User will be generated and placed in appropriate *.g.dart file which will be part of your *.dart file once code generator is complete.
Related
For abstract classes is there difference between implements and extends? Which one should I use? In Java for interfaces you would use implements, but I see dart doesn't have interfaces and both implements/extends work. If I want to declare abstract class for my api methods, should I use implements or extends?
void main() {
User user = new User();
user.printName();
}
abstract class Profile {
String printName();
}
class User extends Profile {
#override
String printName() {
print("I work!!");
return "Test";
}
}
All classes in Dart can be used as interfaces. A class being abstract means you cannot make an instance of the class since some of its members might not be implemented.
extends means you take whatever a class already have of code and you are then building a class on top of this. So if you don't override a method, you get the method from the class you extends from. You can only extend from one class.
implements means you want to just take the interface of class but come with your own implementation of all members. So your class ends up being compatible with another class but does not come with any of the other class's implementation. You can implement multiple classes.
A third options, which you did not mention, is mixin which allow us to take the implementation of multiple mixin defined classes and put them into our own class. You can read more about them here: https://dart.dev/guides/language/language-tour#adding-features-to-a-class-mixins
In my studies of Dart languages, I found some packaged using this kind of class declaration:
class _Base = Authentication with Utilities, Validators;
I don't understand what the operator = is doing here, is it a kind of alias?
Is a shortcut to create inherit classes with mixins.
The example is same to:
class _Base extends Authentication with Utilities, Validators{
_Base(): super(); // or with args
}
Utilities and validators are mixins.
I wish to make DAO layer in my grails project which would be not be associated with any of the domain classes and would be interacting with the secondary database of my project. I get the following error when I try to inject the service in any controller:
"Cannot invoke method abc() on null object"
However, the error is resolved and works perfectly when I initialise the service using the new keyword in the controller but I know that shouldn't be necessary as grails is supposed to handle it. Can anyone tell me what am I missing?
I don't think the issue has anything to do with whether or not the service is associated with a domain class. The DI container doesn't know anything about that.
If you have a controller like this:
// grails-app/controllers/demo/SomeController.groovy
package demo
class SomeController {
SomeService someService
def someControllerAction() {
someService.abc()
// ...
}
}
And a service like this...
// grails-app/services/demo/SomeService.groovy
package demo
class SomeService {
void abc() {
// ...
}
}
That will work fine.
It is almost impossible to say for sure without seeing what your code what you are doing wrong but one possibility is something like this, which will not work:
// grails-app/controllers/demo/SomeController.groovy
package demo
class SomeController {
def someControllerAction() {
// This is a local variable, not
// a property and as such will not
// be subjected to dependency injection.
SomeService someService
// ...
someService.abc()
// ...
}
}
Also, make sure the property name (someService in the sample above) matches the service class name, but with a lower case first letter (more generally, make sure the property name matches the property name representation of the service class name, which is usually as simple as lower casing the first letter of the class name).
So I've been dependency-injecting all facade-referencing classes into my controller today as seen on Taylor Otwell's latest blog post here:
http://taylorotwell.com/response-dont-use-facades/
The following constructor injects its dependencies properly:
public function __construct(
Illuminate\Session\Store $session,
Illuminate\Routing\Redirector $redirect,
Illuminate\View\Environment $view
) {
...
}
I am using the facade class reference for this:
http://laravel.com/docs/facades#facade-class-reference
However, when I try and inject the mailer class, I get the error "class mailer does not exist". I am trying like so:
public function __construct(
Illuminate\Session\Store $session,
Illuminate\Routing\Redirector $redirect,
Illuminate\View\Environment $view,
Illuminate\Mail\Mailer $mailer
)
The class obviously does exist, and the facade class reference appears to be correct too. I don't know what could be causing this error.
I'm additionally having the same problem with the Validator class, but I assume the solution would be the same.
Turns out there was a small bug in the framework source.
I've added some functionality to some of my instance classes in my symfony project that I want ALL of my instance classes to have. If I didn't have any qualms about editing the core symfony installation, I would just add my methods directly to the sfDoctrineRecord class. But I don't want to do that, of course, because my changes would break on upgrade, plus my changes wouldn't port well to other projects.
If I want to add certain functionality to all my instance classes in symfony, what's the "right" way to do that?
(P.S. When I say "instance class", I mean something like lib/model/doctrine/Customer.class.php.)
Steps:
Create myDoctrineRecord
abstract class myDoctrineRecord extends sfDoctrineRecord
{
public function commonRecordMethod() { }
}
I place this file in lib/record, but you can put it anywhere that the autoloader will see it.
Set Symfony to use this class in the configureDoctrine callback of your ProjectConfiguration:
public function configureDoctrine(Doctrine_Manager $manager)
{
sfConfig::set('doctrine_model_builder_options', array('baseClassName' => 'myDoctrineRecord'));
}
That's it! Isn't Symfony great? :)
I suppose the proper way would probably be to add a Doctrine_Template to the models in question, however you would need to define it as a behavior for every model in your schema.yml
class MyMethodsTemplate extends Doctrine_Template
{
public function customMethod1(){
$model = $this->getInvoker();
//do stuff with model
}
public function customMethod2(){
$model = $this->getInvoker();
//do stuff with model
}
}
And then in your schema.yml:
ModelName:
actAs:
MyMethodTemplate: ~
# the rest of your definition
After you rebuild you should be able to call:
$model = new ModelName();
$model->customMethod1();
$model->customMethod2();
Of course Doctrine templates and listeners are much more powerful than that. You should take a look at the documentation for decent overview