I see many instances of # sign like #package_name or #somthing in dart. Although I know the usage of some examples like #override, I can't understand why some packages(eg: #freezed) or dart syntax(eg: #immutable,#lazySingleton) use this operator and what its functionality is.
it's metadata read here about it: dart language-tour
As Kherel mentioned, the # symbol is for metadata. It helps developers keep track of certain functions for future purposes.
If you want, you can then use that metadata for programmatic purposes using the 'dart:mirrors' library.
For example, flutter uses #override to ensure that child classes are allowed their specific behavior, separate from the parents.
The most common usage is to classify functions and classes in some way for easy access. IDEs may also keep track of certain metadata to warn you about the way functions operate (via #TODO or #deprecated, for instance).
Related
I'm a beginner at Flutter/Dart and I keep seeing dollar signs appearing before calls to classes or methods, an example is the following (found in Floor package documentation):
final database = await $FloorAppDatabase.databaseBuilder('app_database.db').build();
I've searched a lot and the only meaning of dollar signs in Dart that I could find is for string interpolation, but this doesn't seem the case.
It's not a Flutter or Dart convention - at least not an official one: the official Dart naming conventions document (as of October 2020) makes no mention of using $ in identifier names.
However, I do know that other programming languages' ecosystems do use a dollar-sign (Sigil) and I think that habit was inherited by the authors of the floor database that you linked to. More specifically, in Java it's commonplace to use a $ prefix for type-names generated by tooling rather than being hand-written (such as ORM entity types, for example), and people using RxJS observables in JavaScript will use a $ as a variable-name suffix.
As $FloorDatabase is a type-name, not a variable or member-name, I'm going to go with the assumption it's a habit picked-up from Java:
Java: The $ character should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems.
So in this case, a clue is in the documentation you linked to:
Use the generated code. For obtaining an instance of the database, use the generated $FloorAppDatabase class, which allows access to a database builder
So that's my conclusion: it's not an official naming convention in Dart/Flutter, but it is in Java, and it seems like the authors of floor carried it over from Java.
(I personally wish they didn't as it isn't a particularly useful indicator - what does it matter to a consuming application if a type was created a tool instead of hand-written?)
Just wondering whether there is any support for comments considered as documentation for enums and classes members (methods and fields / properties) in PowerShell?
If you're referring to the equivalent of Comment-Based Help, I've seen no indication of any. However, if you're writing classes or enums, you are also presumably writing scripts or script cmdlets/advanced functions that rely on them; it wouldn't be unreasonable to document the classes or enums in the scripts/etc. that use them.
Trevor Sullivan provides a link below to building your own about_Topic help data files; this represents another possibility, and one that may well be more appropriate, depending on how you're using your classes/enums.
I have a verification component which is used by many teams. I have a define say ADDRESS_WIDTH and i set it to the max of all the requirements from all the teams.
But that does not look like the ideal solution. Is there a way this can be handled in the SV/UVM way.
I thought of couple of ways
I list this as a parameter in the agent so that people can use defparams to update it, but then also I would need a way to handle interfaces separately.
This leaves a potential hole, where someone might update one place and not change another place.
There is also a command line option to update a define, but that is not ideal solution if the parameter list is too many.
I can have a separate defines file and everyone can have their own defines file, but that would depend on the compilation order.
Please let me know what other better solutions are there.
Thanks in advance.
Use a package to define the parameters that both the interface and verification component will use and therefor keep in sync. Each team can modify the package to suit their needs.
Create another package that specifies the legal range of values for those parameters and have either the interface or verification use assertions to check the values of the team's package.
Now that it's no longer recommended (or possible, given ES6 classes) to use the StylePropable mixin (and because libraries like react-mixin, that try to turn them into decorators have been nothing but trouble), and given that an official replacement hasn't been developed to my knowledge, what's the recommended way to incorporate the behavior (such as auto-prefixing) of the functions it provided, such as prepareStyles? I'm using ^0.14.0.
I would like to know if there is anyone who has implemented the subjectscheme maps of DITA1.2 in their work? If yes, can you please break-up the example to show:
how to do it?
when not to use it?
I am aware of the theory behind it, but I am yet to implement the same and I wanted to know if there are things I must keep in mind during the planning and implementation phase.
An example is here:
How to use DITA subjectSchemes?
The DITA 1.2 spec also has a good example (3.1.5.1.1).
What you can currently do with subject scheme maps is:
define a taxonomy
bind the taxonomy to a profiling or flagging attribute, so that it the attribute only takes a value that you have defined
filter or flag elements that have a defined value with a DITAVAL file.
Advantage 1: Since you have a taxonomy, filtering a parent value also filters its children, which is convenient.
Advantage 2: You can fully define and thus control the list of values, which prevents tag bloat.
Advantage 3: You can reuse the subject scheme map in many topic maps, in the usual modular DITA way, so you can apply the same taxonomies anywhere.
These appear to be the main uses for a subject scheme map at present.
The only disadvantages I have found is that I can think of other hypothetical uses for subject scheme maps such as faceted browsing, but I don't think any implementation exists. The DITA-OT doesn't have anything like that yet anyway.