What are the differences between
inherit nativesdk
and
BBLASSEXTEND="nativesdk"
in a bb recipe?
When you use inherit nativesdk, recipe is made only for nativesdk purpose and must be named nativesdk-myrecipe.bb.
If you want a normal recipe to be also used in nativesdk, you have to extend it by using BBCLASSEXTEND="nativesdk".
Details can be found in Yocto manual.
Related
I just created my first custom Swift class and I noticed that it didn't add the class name when I ceated the swift file, in fact the only thing in that file is the import statement for the foundation. If I'm not mistaken Xcode copies the file name when you create Obj-C classes.
Is it a good naming convention to name your custom classes the same as the file name in Swift/iOS?
Yes it is a good practice. If the IDE doesn't do it, do it yourself for the sake of your sanity. I don't want to open a project with tens of classes where the class Person is defined in file1.swift.
Yes, just like in other languages, it is good practice to name the file the same as the class. It avoids confusion and makes it clear.
I have a class written in Objective-C and I want to have another similar one. Except for few details. Is there any smart way of copying class implementation and making another class? I'd like to change few things, but ctrl+c + ctrl+v sounds so unintuitive.
Regards
PS. edit: I have multiple classes to implement, also I'd like to have neat solution for future.
Use class inheritance.
Implement class A with the common functionality
Derive classes B and C from A to add functional differences.
Take a look at Classes Inherit from Other Classes.
If you like to simply add a method without subclassing, see Categories Add Methods to Existing Classes. But be aware what you shouldn't do with categories!
If you like to change values, add appropriate properties to the interface declaration.
According to the documentation, a Grails controller is simply a class with "Controller" appended to the name and saved in grails-app/controllers/. The simplest of such a class being:
package some.package
class FooController {
def index = {}
}
When the Grails application is run, this controller will inherit some standard methods like getParams and getSession. From the attached screenshot I can see that these are added via groovy.lang.ExpandoMetaClass. What I don't see is how this happens. The controller doesn't implement any interfaces or extend any abstractions. Where do these methods come from?
From Grails 2.0 a new methodology was adapted to add the dynamic methods to the controller artefacts. You can visit them step wise to see how those properties are added to Controllers:-
Controller in grails is not part of grails-core but a plugin by itself to grails named grails-plugin-controllers.
Being a plugin, the corresponding *GrailsPlugin Class would define the behavior of the plugin.
ControllersApi (extending CommonWebApi) bears all those properties which are to added to controller artefact. (Introduced from Grails 2.0)
ControllerGrailsPlugin registers ControllersApi as a spring bean.
There is more to just adding ControllerApi as a bean.
There is a concept of MetaClassEnhancer which would take/consider an API (in this case ControllerApi) and enhance/reconcile the artefact (controller) with the corresponding API by adding CachedMethods to the artefact using reflection, which is the role of a BaseApiProvider present in grails-core.
This magic happens in the Controller plugin class as well.
Now, prior to Grails 2.0 a different method was adapted to add the dynamic properties to controller. That way metaClass properties were added to controllers at runtime which was found to be less efficient. Each of the dynamic property was represented by its own class (viz: GetParamsDynamicProperty, GetSessionDynamicProperty) which is not in use right now.
So what you need to look now in the object tree for those dynamic methods is this where the CachedMethods are available in the controller. Hope that helps. I would be glad to add more if you seek more. :-)
You are right, Grails 'Controllers' are not really Controllers in the sense they inherit from a base class, but rather they are just simple POGOs that follow the convention of being placed in the grails-app/controllers directory. When your application is compiled, 30+ methods are mixed in through AST transformations, the majority of them coming from
org.codehaus.groovy.grails.plugins.web.api.ControllersApi, but also from
org.codehaus.groovy.grails.plugins.converters.api.ConvertersControllersApi,
org.codehaus.groovy.grails.plugins.web.api.ControllersMimeTypesApi.
The preceding was paraphrased from Programming Grails by Burt Beckwith, and I would recommend it if you are interested in the finer details of Grails.
Quoting from Burt Beckwith's excellent book, Programming Grails:
Over 30 methods are mixed into controller classes with AST
transformations. The majority are added from the
org.codehaus.groovy.grails.plugins.web.api.ControllersApi class
ControllersApi source
A rule in xText called "Component" will typically generate a class "Component" in the src-gen folder.
I would like to add additional methods to these classes without them being overridden every time I make minor changes to the DSL. What's the proper way to inject my own code into these classes and is there a way to make all classes extend my own root class instead of the default EObject?
Thanks in advance.
You basically have two choices:
You can use a IXtext2EcorePostProcessor to modify the EMF-model which Xtext inferred from your grammar. The actual code generation is done by EMF, so you have to fiddle your code through that bottleneck. The details are described in a blog of Christian Dietrich. This approach is only suitable for small modifications.
You can use the "generation gap pattern" (a.k. "implementation gap pattern") which allows you the write classes which derive from the generated model classes. Here you can add anything you want. The details are described in a blog of Heiko Behrens. This approach is better suited for large scale modifcations by inheritance.
You may of course mix the two approaches...
I'm trying to define a "Product"-class for my model (.edmx), and I have it in the same folder as the model.
I get: Ambiguity between 'MVCTest.Models.Product.ProductID' and 'MVCTest.Models.Product.ProductID' error
What's needed to do so I can define my classes correctly?
/M
Have you tried using "Partial class"? Only really appropriate if it's an extension of the product class I guess.
If this is not what you were looking for then let us know with more information or even code snippets.
You could always separate out by namespace. Have one class in one namespace. Although having the same class with the same properties is a bit unusual, and suggests that you need to refactor and create some form of inheritance as griegs suggested.