How to create a type alias in Flutter? - flutter

I have seen some old questions/answers that said it's impossible to create a type alias on Flutter. I just want to make sure whether it's the case, as the language seems to have been updated numerous times since.
My specific question is, how can I make a type alias like this:
typealias Json = Map<String, dynamic>;
?
Or is there any workaround, because I've tried to use empty mixin to do this but it says that there are 18 missing method implementations.

Small update on Randai Schwartz's comment.
The feature seems (as of April 2021) almost ready and will probably be released in the next minor version or the one after it.
When you read this, it is probably worth checking the following issue:
https://github.com/dart-lang/language/issues/65
This should allow to do:
typedef NewTypeName = OldTypeName;
Update:
Flutter officially supports now typedefs. :)
So you can just use my code example above.

At this point, typedefs are supported only for Function types (https://dart.dev/guides/language/language-tour#typedefs). There is talk of adding more, but not any time soon (https://github.com/dart-lang/language/issues/115).

Flutter 2.2 has been released together with Dart 2.13, now SimonEritsch code should work as you wanted as long as you run flutter upgrade on your terminal or upgrade your dart.

Related

Is there a method similar to buildArguments()?

There used to be a method named buildArguments() which was very useful for viewing query arguments. It seems that it was removed after the package version 9.0.0.
I was using it to print my queries to the console, so I was able to spot any mistakes. Was a new method introduced to replace buildArguments()?

How can I migrate Dart code to non-nullable (NNBD)?

I have a Flutter application that was written before null safety was introduced to Dart.
I heard of a Null Safety Migration Tooling. How could I use it to convert my code from pre-NNBD to non-nullable by default?
You need at least Dart 2.9. At the time of writing, you can use 2.9.0-10.0.dev, i.e. put the following SDK constraint in your pubspec.yaml:
environment:
sdk: ">=2.9.0-10.0.dev <3.0.0"
Hints (/*?*/ & /*!*/)
The /*?*/ hint means that something should explicitly be nullable.
/*!*/ means that something should be non-nullable.
You can already add these hints manually before using NNBD. Otherwise, you can add them with the tool during migration (see below).
Edits
There are ?, !, and _ edits.
? makes a type nullable after migration. _ makes it non-nullable (meaning no character is changed because non-nullable is the default).
! makes an expression non-nullable.
These edits are previewed in the migration tool.
Using the tool
Dart 2.9 comes with an nnbd_migration package.
This tool can be used to interactively convert code to NNBD.
I will cover the migration steps described in the README and try to simplify them:
Go to your project in your command line and run pub get or flutter pub get when using Flutter. (Note that at the time of writing, the Flutter SDK is not yet supported)
Run dart migrate. (Note that at the time of writing, I need to use --skip-pub-outdated)
Wait for analysis and migration to complete and then view migration suggestions by opening the URL you see in the command line in your browser (of format http://localhost:<port>/<project path>?authToken=<token>). You should see something like this:
Select a file to begin with. It should look something like this:
View the proposed edits on the right (matching the highlighted characters):
If you find edits that you think are not correct, find the root cause in Edit Details:
You can scroll down to trace the root expression that led to the edit proposal. When you find some wrong decision somewhere along the way, you either Add /*?*/ hint or Add /*!*/ hint as explained above (you can also add them manually in your IDE).
If an edit looks right, you do not need to do anything.
You will probably need to Rerun From Sources a lot. This will apply the new hints you added and any other edits you made to the code and generate new edits. Do this until all edits look right.
Now, you might see your hints highlighted in red, which means that the tool will remove the hints and convert them to either ?, !, or blank.
You should probably save your project at this point (e.g. git commit).
Note: at this point, your code has a bunch of added /*?*/ and /*!*/ hints and has not yet been migrated.
Apply Migration: this will apply the proposed edits and remove all hints.
Probably leave the migration tool open for now.
Now, you do not have any hints in your code anymore.
Test your project (pub get or flutter pub get and then run).
If something went wrong, it is helpful to have left the migration tool open.
Potentially, you want to revert your version to before the migration and repeat the steps.
Success! Your project is now null safe 🙌🏽

Kaitai Struct Parameter Type

I am trying to pass a parameter to ksy file. The parameter is of type another ksy file. The reason is that i need to access all the fields from the ksy file passed as parameter.
Is that possible?
If yes, would you please provide me with syntax code snippet so I can mimic it.
If no, what would be another solution?
Thank You.
Affiliate disclaimer: I'm a Kaitai Struct maintainer (see my GitHub profile).
First, I recommend always using the development version of the Kaitai Struct Web IDE (https://ide.kaitai.io/devel/), not the stable one. The stable IDE deployed at https://ide.kaitai.io/ has KS compiler of version 0.8, which is indeed the latest stable version, but already 2 years old at the moment. But the project is under active development, new bug fixes and improvements are coming every week, so the stable Web IDE is pretty much outdated. And thanks to the recent infrastructure enhancement, the devel Web IDE now gets rebuilt every time the compiler is updated, so you can use even the most recent features.
However, you won't be able to simulate the particular situation you describe in the Web IDE, because it can't currently handle top-level parameteric types (there is no hook where you can pass your own values as arguments). But it should work in a local environment. You can compile the commontype.ksy and pty.ksy specs in the Web IDE to the target language you want to use (the manual shows how to do it). The code putting it together could look like this (Java):
Commontype ct = new Commontype(new ByteBufferKaitaiStream(new byte[] { 80, 75 }));
Pty r = new Pty(
new ByteBufferKaitaiStream(new byte[] { 80 }), // IO stream
ct // commonword
);
Note that the actual parameter order of the Pty constructor may be different, e.g. in Python come the custom params (commonword) first and then the IO object. Check the generated code in your particular language.

why is it possible to set $GLOBALS['TBE_STYLES']['logo'] in typo3conf/extTables.php, but not in typo3conf/AdditionalConfiguration.php?

just out of curiosity:
As you all might or might know, it is possible to set a custom BE logo with $GLOBALS['TBE_STYLES']['logo'] = '../fileadmin/mylogo.png'; in typo3conf/extTables.php.
This behavior is working since old v4.x times.
But I just read that extTables will be deprecated in v8.x.
I tried to find a simple solution to this (one that keeps that one-line simplicity and does NOT require me to create&install an extension!)
I moved this line to typo3conf/AdditionalConfiguration.php,
but it does not work from there.
Why?
What would be necessary to make this line work within typo3conf/AdditionalConfiguration.php ?
In TYPO3 8.x you'll be able to change a backend logo via EXT:backend, so you should stick to that approach. Read more in release notes.
UPDATE.
To answer your question, why TBE_STYLES defined in AdditionalConfiguration are ignored: take a look at unsetReservedGlobalVariables() method from \TYPO3\CMS\Core\Core\Bootstrap class. It is executed after all the configuration is initialized (Local and Additional are merged and populated) and explicitly calls unset($GLOBALS['TBE_STYLES']);.

Perl changing the current package?

Without using a source-filter, is there a way to change the current running package? I'm trying to accomplish the same thing oose.pm does, and I'm wondering if I can drop my users in a non-main package.
I think you'll be able to do that by changing PL_curstash and PL_curstname on the C level.
PL_curstash = gv_stashpvs("Some::Package", GV_ADD);
sv_setpvs(PL_curstname, "Some::Package");
PL_curstash is the stash of the current package during compilation, PL_curstname is its name.
Update:
I've found this problem kind of interesting and implemented the solution as Devel::ChangePackage. Turns out what I initially suggested just works. You can get it either from http://github.com/rafl/devel-changepackage, or from a CPAN mirror near you once they have updated.