I am using Polymer 1.0 and I am in need of some constant variables in my .js file. Example:
const REQUEST_URL = '/test';
Polymer({
...
// use REQUEST_URL a few times
...
});
The problem with this approach is that if REQUEST_URL is defined multiple times in different files, they will collide and result in SyntaxError: Identifier 'REQUEST_URL' has already been declared.
What is the preferred way to define constant variables on a per-file basis in Polymer?
For constants that differ between files, just use a private property by prefixing with _. For constants that need shared, you could do the same thing but in a behavior in a separate file that can be imported into any file that needs those constants.
properties: {
_requestUrl: {
type: String,
value: '/test'
}
}
For behavior do the same thing but treat as behavior. https://www.polymer-project.org/1.0/docs/devguide/behaviors
Related
Component A own a set containing pointers, I plan to design a API to return the set.
Currently other component only read the content of set, no intention to change anything, which shall I return from the API.
Options are:
1. Return a copy of the set
2. Return an reference of the set
3. Return a pair of the iterator of set. std:pair<ForwardIterator begin, ForwardIterator end>
Concern is:
1. Maybe some overhead to copy.
2. This expose the internal set, it can not stop other components to change it.
3. If component A modify the set, will it invalid the iterator?
For the time being let's assume you're sure about this: ComponentA owns
a set of pointers, std::set<Thing *>, and you want it to have a method to return that set, but
so that the receiving client code cannot modify it. You're unsure whether to:
Return a copy of the set.
Return a reference to the set.
Return the [begin(), end()) range of the set.
Don't do any of those. Each one has the flaw that you have identified yourself,
and 3 has the additional flaw that it doesn't return the set. The client
code receiving the iterator range won't know that it delimits a set and
won't be able to take advantage of the defining properties of a set.
Instead, return a const reference to the set from a const method:
struct ComponentA
{
...
...
std:set<Thing *> const & get_set_of_things() const {
return things;
}
private:
std::set<Thing *> things
...
};
This removes the drawback of 2 - client code can't modify the set through
a const reference - and it doesn't have any of the other snags.
I hope that answers your question, but I'm afraid it's not the end of your design problems.
Client code can't modify things through the
std:set<Thing *> const & returned by get_set_of_things(). But
the things that I can't modify are the members of that set, which are merely
pointers to Thing. I certainly don't care what those pointers are - memory addresses like
0x1a04c20 - and I have no interest in modifying them. But nothing
is stopping me from modifying any of the Things that those pointers
point to, e.g.
ComponentA ca;
...
auto const & things = ca.get_set_of_things;
Thing * pthing = *things.begin();
thing->modify();
...
This modifies one of the Things controlled by ca - which is what you
want to prevent.
However you return the set from a ComponentA object, you can't prevent the client from modifying
the Things controlled by the object as long as you are giving them Thing *-pointers.
Well you could block this threat by changing things to a set of const
pointers:
struct ComponentA
{
...
...
std:set<Thing const *> const & get_set_of_things() const {
return things;
}
private:
std::set<Thing const *> things
...
};
But the fallout of that change is that now ComponentA itself can't
modify any of the Things controlled by things. Can you live with that?
And this is just the first of several loud design alarms that are triggered
by the information that your ComponentA controls a set of pointers.
I suggest you draft your class definition and put it up for
comment on SO's sister-site Code Review.
It's beyond the scope of SO to explore all the likely pitfalls, especially
in the absence of any code.
I know that every JavaScript object has an internal property called [[Prototype]]. Some implementations allow access to it via a property called __proto__ while other do not. Is there any special significance of the brackets surrounding this property?
It is an "internal property" of the object. From ECMAScript 8.6.2:
This specification uses various internal properties to define the semantics of object values. These internal properties are not part of the ECMAScript language. They are defined by this specification purely for expository purposes. An implementation of ECMAScript must behave as if it produced and operated upon internal properties in the manner described here. The names of internal properties are enclosed in double square brackets [[ ]].
The statement, "These internal properties are not part of the ECMAScript language," means that internal properties are not identifiers that can be used in actual code -- internal properties are not accessible as members of the objects that contain them. However, they may be made accessible by particular functions or properties (e.g., some browsers are kind enough let you set and get [[Prototype]] through the __proto__ property, and the ES5 spec allows read-only access through Object.getPrototypeOf).
The use of double brackets over single brackets is probably to avoid any possible confusion with actual bracket notation (i.e., property access).
JavaScript [[Prototype]]
The double bracket [[Prototype]] is an internal linkage that ties one object to another.
When creating a function, a property object called prototype is being created and added to the function's name variable (that we call constructor). This object points to, or has an internal-private link to, the native JavaScript Object).
Example:
function Foo () {
this.name = 'John Doe';
}
// Foo has an object 'property' called prototype
// prototype was created automatically when we declared the function Foo.
// Now, we can assign properties to it without declaring the prototype object first.
Foo.prototype.myName = function () {
return 'My name is ' + this.name;
}
Now, if we'll create a new object out of Foo using the new keyword, we basically creating (among other things) a new object that has an internal link to the function's prototype (Foo) we discussed earlier:
var obj = new Foo();
obj.__proto__ === Foo.prototype // true
obj.[[Prototype]] === Foo.prototype // true
as
obj.__proto__ === obj.[[Prototype]] // true
Since [[Prototype]] is a private linkage to that function's object, many browsers are providing us with a public linkage instead. That is the __proto__ (pronounced as dunder proto).
__proto__ is actually a getter function that belong to the native JavaScript Object and returns the internal-private prototype linkage of whatever the this binding is (returns the [[Prototype]] of obj):
obj.__proto__ === Foo.prototype // true
BTW, starting from ES5, we can use the getPrototypeOf method to get the internal private linkage:
obj.__proto__ === Object.getPrototypeOf(obj) // true
NOTE: this answer doesn't intend to cover the whole process of creating new objects or new constructors, but to help better understand what is the [[Prototype]] and how it works.
The reason it's in brackets is to denote that it's a private property. The brackets themselves are never used in code anywhere.
As you pointed out, some implementation provide access to that private property under __proto__, but it's non-standard.
Synopsis
How do you declare variables in a namespace while using the use statement? (ie., without declaring the namespace with the variable name)
How do you reference namespace variables with the "use" statement without a container reference. (ie., trace(foo) rather than trace(a.foo) [seems kinda pointless if I have to state this after already switching to the namespace])
Explanation
Having read Grant Skinner's "Complete Guide to Using Namespaces", and other articles, such as Jackson Dustan's "Better OOP Through Namespaces", I'm left with the above unanswered questions. I feel as though I'm missing some basic principle, but I can't seem to get namespaces to work. The following examples are written for use with the Flash IDE, so assume the following...
locus.as
package com.atriace {
public namespace locus = "atriace.com";
}
testA.as
package com.atriace {
public class testA {
import com.atriace.locus;
locus var foo:String = "Apple";
public function testA() {}
}
}
testB.as
package com.atriace {
public class testB {
import com.atriace.locus;
use namespace locus;
public function testB() {
trace(foo);
}
}
}
Document Class:
import com.atriace.testA;
import com.atriace.testB;
var a:testA = new testA();
trace(a.foo); // results in "Apple"
var b:testB = new testB(); // compile error: variable "foo" not defined.
Issue #1
In my mind, a namespace is little more than an object to hold variables that has scope level access. Ergo, global is a namespace visible to all functions (since it's the root scope), local is namespace (specific to the current and child scopes), and so on. If true, then switching to a namespace with use should allow you to simply declare variables that happen to exist in both the local and custom namespaces. For example:
use namespace locus
var bar:String = "test"; // this now *should* exist in both local & locus scope/namespace.
Since I'm unaware of a method to iterate over a namespace like a normal object, I don't know whether this is what happens. Furthermore, I haven't seen any cases where someone has declared a custom namespace variable this way, so I assume namespace variables must always be explicitly defined.
Issue #2
You might ask, "what's the goal here?" Quite simply, we want a dynamic pool of variables and methods that any new classes can add to (within the same package). By switching to this namespace prior to calling methods, we can reduce the wordiness of our code. So, class.method() becomes just method().
In testB.as we'd fully expect an error to occur if we never imported the testA.as class and instantiated it; especially because foo isn't a static member of the class (nor do we want it to be). However, since we've instantiated foo at least once, the namespace locus should now have a variable called foo, which means that when testB.as gets instantiated, and the constructor seeks a value for foo, the namespace already has one.
Obviously, there's a flaw in this thinking since the Flash compiler complains that foo has never been declared, and the only way I can reference foo from the document class is by referencing the container (ie., a.foo rather than just switching to the namespace with use, and tracing foo directly).
For the sake of argument, neither inheritance nor static members are a solution to this dilema. This is both an excercise in learning better code techniques, and an answer to the structure of a large utility class that has complicated dependencies. Given the absence of a variable/method, you could simply code around it.
I know it's not a heavily documented topic, which is why I'm hoping some sage here may see what I'm missing. The help would be much appreciated. :)
"use namespace" is for the consumer side. You always have to include the namespace in any declaration:
MyNamespace var foobar : uint;
If you wish to add namespaced package-global variables (you shouldn't as a general rule), you have to define each one of them in a separate .as file as packages only allow one publicly-visible definition per file at the top-level.
In your example above you are using namespaces incorrectly. A namespace can span multiple classes, but does not achieve the cross-class functionality you are looking for. This is more the domain of aspect-oriented programming.
I have 5000 data item definition configuration which we are expecting to be designed like,
-- Name of the device
VARIABLE Name {
type=Float,
length=20,
<<few more definition here>>
}
-- The device running elapsed time since its last boot
VARIABLE BootTime {
type=Integer,
<<few more definition here>>
}
I will be reading the value of "Name", "BootTime" from a device using diffent communication protocol where we use the above property defined.
I want the VARIABLE to also have properties to pre_processor and post_processor functions.
How to define the structure like this in Lua? If this strcuture is not possible, what is the closet structure possible in Lua
I want to overload operator for this Variable definitions so that I can do,
I can configure BootTime = 23456789 or
Do arithmetic like BootTime + 100 (milliseconds)
Or comparison like if BootTime > 23456789 then do something
If you can ditch the keyword VARIABLE then the code is Lua and you only need a little support code (some __index metamethod magic).
Integer="Integer"
setmetatable(_G,
{ __index = function(t,n)
return function (x) _G[n]=x.value end
end })
BootTime {
type=Integer,
value=10000
}
print(BootTime+2345)
If you want to keep the keyword VARIABLE then the syntax you gave is no longer plain Lua but if you can live with VARIABLE.BootTime or VARIABLE"BootTime" or VARIABLE[BootTime]then it is plain Lua and can be made to work with suitable metamethods.
Action script is developed based on object oriented programming but why does it not support function overloading?
Does Flex support overloading?
If yes, please explain briefly with a real example.
As you say, function overloading is not supported in Action Script (and therefore not even in Flex).
But the functions may have default parameters like here:
public function DoSomething(a:String='', b:SomeObject=null, c:Number=0):void
DoSomething can be called in 4 different ways:
DoSomething()
DoSomething('aString')
DoSomething('aString', anObject)
DoSomething('aString', anObject, 123)
This behavior maybe is because Action Script follows the ECMA Script standard. A function is indeed one property of the object, so, like you CAN'T have two properties with the same name, you CAN'T have two functions with the same name. (This is just a hypothesis)
Here is the Standard ECMA-262 (ECMAScript Language Specification) in section 13 (page 83 of the PDF file) says that when you declare a function like
function Identifier(arg0, arg1) {
// body
}
Create a property of the current variable object with name Identifier and value equals to a Function object created like this:
new Function(arg0, arg1, body)
So, that's why you can't overload a function, because you can't have more than one property of the current variable object with the same name
It's worth noting that function overloading is not an OOP idiom, it's a language convention. OOP languages often have overloading support, but it's not necessary.
As lk notes, you can approximate it with the structure he shows. Alternately, you can do this:
public function overloaded(mandatory1: Type, mandatory2: Type, ...rest): *;
This function will require the first two arguments and then pass the rest in as an array, which you can then handle as needed. This is probably the more flexible approach.
There is another way - function with any parameters returns anything.
public function doSomething(...args):*{
if(args.length==1){
if(args[0] is String){
return args[0] as String;
}
if(args[0] is Number){
return args[0] as Number;
}
}
if(args.length==2){
if(args[0] is Number && args[1] is Number){
return args[0]+args[1];
}
}
}
You can't overload, but you can set default values for arguments which is practically the same thing, but it does force you to plan your methods ahead sometimes.
The reason it doesn't is probably mostly a time/return on investment issue for Adobe in designing and writing the language.
Likely because Actionscript looks up functions by function name at runtime, rather than storing them by name and parameters at compile time.
This feature makes it easy to add and remove functions from dynamic objects, and the ability to get and call functions by name using object['functionName'](), but I imagine that it makes implementing overloading very difficult without making a mess of those features.