The OpenZeppelin PaymentSplitter contract has a release() function that sends ETH out to account holders. It's a public virtual function. But, if I go to override it, it won't compile b/c it's got private vars inside. My ultimate goal is to restrict release() so that random people can't just fire it off via Etherscan -- for example making it onlyOwner or otherwise restricting it to a role, and/or making it internal instead of public? I'm wondering what the best approach would be. Seems like I could copy the entire solidity file into my own contract, but I'm wondering if a more elegant approach exists. Ideas/thoughts appreciated!
Just to document a working answer: I did copy the entire contract and then made release() internal. Everything seems to work fine that way, although I'm still unsure whether some more elegant way exists.
Related
I'm modifying a code written in c++ in order to add several features required by my company. I need to modify as less as possible this code, because it's a public code get from a Git repository, and we want to avoid to deviate from the original source code in case we need to synchronize our code with possible new versions in the future.
In this code, a structure is initialized with a call to std::memset. And I had need to add a shared pointer to this structure.
I notice no issue about that, the code compiles, links and works as expected, and I get even no warnings while the compilation.
But is it safe to achieve that this way? May a std::shared_ptr be correctly initialized if it is part of a structure initialized with std::memset? Or are side effects or hazardous issues which prevent to do that?
I'm using tdlib and currently trying to create another user's profile screen like this one:
There is usually a field on this screen called "Notifications" containing information on whether or not notifications for given user are muted and if so then for how long. All other fields seem easy to retrieve, but this one is a head-scratcher for me.
All other field are stored in User entity, but what am I supposed to do with this one? Call createPrivateChat only to get one field (namely notificationSettings)? This seems like overkill to me. Isn't there easiest ways to get this? In this issue sapelkinAV states that "chatID is equals UserId". Is it correct? Even if so it might just be an internal thing that we shouldn't rely on, and I can't find neither proofs nor restrictions on abusing this "feature".
If it is fine, than I could use getNotificationSettings and pass notificationSettingsScopeChat as scope parameter. Would it be the right solution? Any thoughts and advices are appreciated!
Official answer (obtained from TDLib bot):
Your usage of createPrivateChat is absolutely correct. To get correct NotificationSettings you need to get information about the corresponding chat.
So I ended up doing exactly that.
Call createPrivateChat only to get one field (namely notificationSettings)?
Simple question -- how do you expose constants in a java google app engine Endpoints API?
e.g
public static final int CODE_FOO = 3845;
I'd like the client of the Endpoints to be able to match on CODE_FOO rather than on 3845. I'll end up doing enum wrappers (which probably is better anyway) but I'm just starting to be curious if this is even doable? Thx
Note that this isn't a full answer but here is a workaround: in Android Studio, create a very light-weight "common" java project and shove anything you want to keep in sync there such as constants as well as common types that you want exposed (e.g. an enum representing all possible return / error codes, etc).
This way you should get pretty decent compiler-time safety and keep these guys in sync.
Please feel free to comment if anyone has better suggestions.
This is unfortunately a Law of Information (ahem). If you have a message protocol you defined, both sides of the interaction need to be aware of the messages that could be passed. There's no other way for the client to be aware of what it needs to respond to. Ajax libraries hard-code the number "200" to be able to detect a successful request, as one example.
Yes, just use a switch statement on strings inside your client code. Or, you could use a dictionary of strings pointing to functions and just call the function after de-referencing the dictionary given the string you got.
I know it sounds like a stupid question, but how safe is your API if you can access private properties and change them?
What's the point of having locks on your door when people can just kick the door down? Using reflection requires more skill and more effort. For the most part the code is fine. Reflection doesn't work well in non full trust environments anyway.
In a language not supporting reflection there's always a possibility of circumventing API through direct memory access.
Encapsulation is not about protecting your API from misuse, it is about hiding away parts of code that are subject of change. If client code uses official interface - it will continue to work after such a change. If not, it was author of this code who just have shoot his foot.
Well, in .NET at least, you can disallow reflection by using .NET permissions.
Also, the purpose of visibility levels in classes and class members is not only the access security. It is also a means to organize and document your code: when you see a private member you know that it is not intended to be used outside the class, and while maybe you can use it via reflection, you will normally not do it as it can cause unexpected behavior in your application.
Anyway I find this question sort of like "What's the purpose of doors having locks if I can smash them with a big enough hammer?" :-)
That's right, its not totally safe, but reflection can also be immensely useful. But you can still only set a property if it has a setter, so it isn't all "bad".
Eventhough reflection is very useful indeed, it's considered an indirect method of changing properties and not nesseserily a method that should be endorsed or supported by your API.
Having said that, by setting a private property, ensures that it won't be changed by those accessing it by normal means
The use of private properties is with reflection the same as without it, but if one considers using reflection to access private members in a third-party class, he should be very sure to know what he does - and he sure knows that this can break operability.
You can prevent access to private properties by installing a SecurityManager. So if you need it, you can really make it private (and pay the price: some 3rd party libraries won't work anymore).
Like laws, private are a price tag. They say "if you don't follow the rules which I impose, there'll be a price to pay." It doesn't mean you must follow the rules (just like outlawing killing people didn't stop murder).
Over the past three weeks, I have lost at least 120 man hours because of some lesser known functionality in ActionScript 3. One of the problems was that, with Internet Explorer, if there are too many messages sent through LocalConnections, it will slow the messages sent through, but in the standalone player and in Firefox, this threshold is significantly higher. Another was that the static values of a class are instantiated even if the member itself is not being used:
import path.to.FooClass;
private function thisIsNeverCalledButItEnsuresThatFooClassIsImported():void
{
var f:FooClass = new FooClass();
}
Since FooClass had a static reference to a Singleton, that Singleton was instantiated so when I loaded a Module which used that Singleton, it would bind to values in an unpredictable way.
Additional cases where things behave in an unexpected way:
MovieClip.addFrameScript
flash.trace.Trace as a class
int is a faster incrementer class, Number is faster for mathematics, and uint is incredibly slow.
PrintDataGrid, if it has only one page, needs to have an empty value appended to the end of its dataProvider
If you use try...catch around two LocalConnections and connect them to the same channel, you will force garbage collection without needing System.gc
So here's the question (and I'm sorry for omitting this in the original post), is there any consolidated documentation for this type of behavior anywhere? Is there any (even non-Adobe) documentation on these issues (websites, forums, books, ANYTHING)? I know that these things are definitely easy enough TO document, but has anyone done so?
If not, am I missing anything? Are there other issues which I should know about?
This kind of useful information is very often not "centralized". Moreover, what you are looking for is something related to the experience of the programmer (more than to official docs).
FYI, there are two other methods for ensuring a class is included.
#1 - This syntax is actually used in the Flex source code:
import path.to.FooClass; FooClass; // note double reference
public class References
{
// No references needed in this class
}
#2 - Use the includes command line argument
-includes path.to.FooClass
You can always submit your experience using the "feedback" section in the help. Unfortunately, this is less obvious than the link that used to be at the bottom of each page in the older help files (which also served the useful function of opening a browser window with the web version of that help page).
Adobe says that it incorporates the comments from previous versions of the help into new versions, but my own observation suggests that there are instances where it does not happen. However, that and the appropriate cookbook are still the best avenue for those who believe that this kind of information should be centralized.
Note that the whole purpose behind modules is to avoid compiling code multiple times, so importing FooClass kind of defeated the purpose. The problems you had in this instance are just one of the many that happen if you use Singletons, and it's unfortunate that the first official Framework, Cairngorm, encouraged their widespread use. Check out http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/ .