In short, how can I combine these two lines of code?
import * as php from './php';
import {str_replace, trim} from './php';
I can't find a syntax that works. I've tried things like
import {str_replace, trim}, * as php from './php';
N.B. this is ECMAScript 2015 (6th Edition, ECMA-262).
You cannot combine these in ES6 indeed. You can only use namespace imports or named imports together with a default import, but not with each other.
The solution is either to keep the two lines, or just use php.str_replace and php.trim everywhere in the code and drop the named imports.
Related
I'm trying to pickle functions with dill. I want to include the whole function and not just a reference to it. Here are my two files:
fun.py:
import dill
from foo import ppp
def qqq(me):
return me + 1
print(dill.dumps(ppp, protocol=4, recurse=True, byref=True))
print(dill.dumps(qqq, protocol=4, recurse=True, byref=True))
And foo.py
def qqq(me):
return me + 1
When I run fun.py I get the following output:
b'\x80\x04\x95\x0f\x00\x00\x00\x00\x00\x00\x00\x8c\x03foo\x94\x8c\x03ppp\x94\x93\x94.'
b'\x80\x04\x95\x90\x00\x00\x00\x00\x00\x00\x00\x8c\ndill._dill\x94\x8c\x10_create_function\x94\x93\x94(h\x00\x8c\n_load_type\x94\x93\x94\x8c\x08CodeType\x94\x85\x94R\x94(K\x01K\x00K\x01K\x02KCC\x08|\x00d\x01\x17\x00S\x00\x94NK\x01\x86\x94)\x8c\x02me\x94\x85\x94\x8c\x06fun.py\x94\x8c\x03qqq\x94K\x04C\x02\x00\x01\x94))t\x94R\x94}\x94h\rNN}\x94Nt\x94R\x94.'
I want to be able to make the first line of output be more similar to the second line, and actually encapsulate the function without the need for a context when reloaded later. Is there a way to do this?
Thanks so much!
James
If the module (foo) is installed on both computers, then there should be no need to do anything but import the function. So, I'll assume the question is in regard to a module that is only installed on the first machine.
It also depends on whether the module foo is "installed" on sys.path or is just available in the current directory. See:
https://github.com/uqfoundation/dill/issues/123
If it's only available in the current directory, either use dill to pickle the file itself or use something like dill.source.getsource to extract the source of the module as a string, and then transfer the string as a "pickle" (this is what ppft does).
Generally, however, dill pickles imported functions by reference, and thus assumes they are available on both sides of the load/dump.
I have a huge list of permissions, and I'm only interested in importing three of them. I'm also interested in grouping them in an object and assigning a variable to that object.
Can I do any better than the following?
import {
firstPermission,
secondPermission,
thirdPermission,
} from '#constants/permissions';
const relevantPermissions = { firstPermission, secondPermission, thirdPermission };
I was inclined to try using the as keyword in the import step, but I couldn't get any such thing to work.
(This feels like an ignorant question; please forgive.)
as keyword is intended to import named exports under different names, not group them.
The code listed in the question is the way this should be done. If relevantPermissions is supposed to be used in multiple places, it's beneficial to re-export them:
export {
firstPermission,
secondPermission,
thirdPermission,
} from '#constants/permissions';
...
import * as relevantPermissions from './relevant-permissions';
This way named imports have a chance to be tree-shaken if some of them remain unused, also may get other benefits of ES modules such as improved code completion in IDEs.
I found some import statements of my .ts files in ionic projects are written as:
import { Component } from '#angular/core'
instead of
import { Component } from '#angular/core';
,which misses a semicolon, and the projects seems run normally, is the import statement need a semicolon at the end actually?
Javascript only requires semicolons to separate statements in the same line. However I'd recommend you to stick to the good practices and use them.
From the style guide for typescript
Use semicolons:
Reasons:
Explicit semicolons helps language formatting tools give consistent results. Missing ASI (automatic semicolon insertion) can trip new devs e.g.
foo() (function(){})
will be a single statement (not two).
I understand that ultimately this is a matter of style, as you shouldn't have any issues if you don't use them when they are not strictly required, although in order to be consistent, it's better to use them than not.
This is a pretty good article also. https://www.codecademy.com/blog/78
Hope this helps!
OP is asking about if semicolons are required in an import statement.
Use semi colons when declaring variables, returning something or making variable calls, as you are declaring a variable with the import it is my understanding that you should use a semicolon.
In perl, sometimes it is necessary to specify the function name in the use statement.
For example:
use Data::DPath ('dpath');
will work but
use Data::DPath;
won't.
Other modules don't need the function names specified, for example:
use WWW::Mechanize;
Why?
Each module chooses what functions it exports by default. Some choose to export no functions by default at all, you have to ask for them. There's a few good reasons to do this, and one bad one.
If you're a class like WWW::Mechanize, then you don't need to export any functions. Everything is a class or object method. my $mech = WWW::Mechanize->new.
If you're a pragma like strict then there are no functions nor methods, it does its work simply by being loaded.
Some modules export waaay too many functions by default. An example is Test::Deep which exports...
all any array array_each arrayelementsonly arraylength arraylengthonly bag blessed bool cmp_bag cmp_deeply cmp_methods cmp_set code eq_deeply hash
hash_each hashkeys hashkeysonly ignore Isa isa listmethods methods noclass
none noneof num obj_isa re reftype regexpmatches regexponly regexpref
regexprefonly scalarrefonly scalref set shallow str subbagof subhashof
subsetof superbagof superhashof supersetof useclass
The problem comes when another module tries to export the same functions, or if you write a function with the same name. Then they clash and you get mysterious warnings.
$ cat ~/tmp/test.plx
use Test::Deep;
use List::Util qw(all);
$ perl -w ~/tmp/test.plx
Subroutine main::all redefined at /Users/schwern/perl5/perlbrew/perls/perl-5.20.2/lib/5.20.2/Exporter.pm line 66.
at /Users/schwern/tmp/test.plx line 2.
Prototype mismatch: sub main::all: none vs (&#) at /Users/schwern/perl5/perlbrew/perls/perl-5.20.2/lib/5.20.2/Exporter.pm line 66.
at /Users/schwern/tmp/test.plx line 2.
For this reason, exporting lots of functions is discouraged. For example, the Exporter documentation advises...
Do not export method names!
Do not export anything else by default without a good reason!
Exports pollute the namespace of the module user. If you must export try to use #EXPORT_OK in preference to #EXPORT and avoid short or common symbol names to reduce the risk of name clashes.
Unfortunately, some modules take this too far. Data::DPath is a good example. It has a really clear main function, dpath(), which it should export by default. Otherwise it's basically useless.
You can always turn off exporting with use Some::Module ();.
The reason is that some modules simply contain functions in them and they may or may not have chosen to export them by default, and that means they may need to be explicitly imported by the script to access directly or use a fully qualified name to access them. For example:
# in some script
use SomeModule;
# ...
SomeModule::some_function(...);
or
use SomeModule ('some_function');
# ...
some_function(...);
This can be the case if the module was not intended to be used in an object-oriented way, i.e. where no classes have been defined and lines such as my $obj = SomeModule->new() wouldn't work.
If the module has defined content in the EXPORT_OK array, it means that the client code will only get access to it if it "asks for it", rather than "automatically" when it's actually present in the EXPORT array.
Some modules automatically export their content by means of the #EXPORT array. This question and the Exporter docs have more detail on this.
Without you actually posting an MCVE, it's difficult to know what you've done in your Funcs.pm module that may be allowing you to import everything without using EXPORT and EXPORT_OK arrays. Perhaps you did not include the package Funcs; line in your module, as #JonathanLeffler suggested in the comments. Perhaps you did something else. Perl is one of those languages where people pride themselves in the TMTOWTDI mantra, often to a detrimental/counter-productive level, IMHO.
The 2nd example you presented is very different and fairly straightforward. When you have something like:
use WWW::Mechanize;
my $mech = new WWW::Mechanize;
$mech->get("http://www.google.com");
you're simply instantiating an object of type WWW::Mechanize and calling an instance method, called get, on it. There's no need to import an object's methods because the methods are part of the object itself. Modules looking to have an OOP approach are not meant to export anything. They're different situations.
I'm trying to use react-native-vector-icons with ES6 in React Native, but unfortunately I'm having trouble importing the icons. Their documentation still uses the old require statement, so I don't think it's helpful.
This is my import:
import {Ionicons} from './node_modules/react-native-vector-icons/Ionicons.js';
This is my usage:
<Ionicons name="ios-book" color="#4F8EF7" />
The error I receive is:
Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined.
It's clear that Ionicons is undefined, so I'm aware that fundamental about the import statement is wrong.
import Ionicons from 'react-native-vector-icons/Ionicons';
import {x} from 'abc'; translates to var x=require('abc').x, not to var x=require('abc').
So what about :
import * as Ionicons from './node_modules/react-native-vector-icons/Ionicons.js';
I ended up using an import statement as follows:
import {default as Icon} from '../node_modules/react-native-vector-icons/Ionicons';
This is because after I followed #Olivier's advice, I ended up with an object that contained a number of properties and I couldn't just use <Icon> as a component, but I discovered that <Icon.default> worked.
Thanks to all who answered!