The Uniswap router contract has a few methods ending in *SupportingFeeOnTransferTokens, e.g. swapExactTokensForETHSupportingFeeOnTransferTokens.
https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/UniswapV2Router02.sol
I vaguely (think I) understand that these methods are supposed to be called for swapping tokens that somehow take a tax/rake during transfers.
I have a few questions regarding these:
In a nutshell, what is the difference in behavior for these functions different from the regular swap functions? Do they somehow interact with the minOut parameters?
How does the Dex UI know which method to call? How does it know the SupportingFee version needs to be called instead of the standard swap?
What happens if my web3 script calls the wrong version of the method? Failures? Wrong amounts out?
I am taking a udemy course and I encounter a code like this
https://github.com/acloudfan/Blockchain-Course-Basic-Solidity/blob/93ca256bcf8c436c144425291257dcff5c3b269f/test/constants_payable.js#L45
I am confuse why the call to a method is called directly instead of using .call or something, wherein if I do google, the way to call a method of a contract is either using .call or .send but at this point the author just calls it directly, is this allowed, why?
here is the contract code
https://github.com/acloudfan/Blockchain-Course-Basic-Solidity/blob/master/contracts/ConstantsPayable.sol
More or less, what is the context of calling smart contract method from a truffle test here? is it like the real environment where it waits for the transaction to be mined before returning or do tests just directly calls it like an ordinary function?
I am posting it here since the author of the udemy course is non responsive and its almost a week and more than a dozen Q&A question are not answered, so the author probably is busy or forgets about the course already (as it is kinda old course but reviewed well).
Before Truffle returns the contract instance (line 41), it uses the ABI interface (provided by the Solidity compiler) to build a map of JS functions for interacting with the contract, including receiveEthers().
what is the context of calling smart contract method from a truffle test here
Even though Truffle JS tests can be connected to a public testnet or mainnet, it's usually used together with another Truffle tool - local EVM and blockchain emulator called Ganache (see the config file where the author defines connection to a local blockchain). By default, Ganache mines a block after each transaction so that you (as a developer or a tester) don't need to worry about mining and other processes in setting up the network, and the response from the local blockchain it returned almost instantly.
if I do google, the way to call a method of a contract is either using .call or .send
Answering only about Truffle. Other packages such as Web3js or Ethers.js might have slightly different rules. And there are .call() and .send() methods in Solidity (for interacting with other contracts or addresses), that also behave differently than explained here:
You can interact with a contract in two different ways:
transactions (can make state changes - change contract storage, emit events)
calls (only read the contract data - no state changes)
By default, if you don't specify whether you want to make a transaction or a call, Truffle makes a transaction. You can override this decision and make a call instead by using the .call() method.
The .send() method is only used for low-level built transactions. A common use case is sending ETH - you need to build the transaction data field, fill the (ETH) value, and call the .send() method (assuming you have configured Truffle to use your private key to sign the transaction).
I'm working on updating some smart contracts to deploy on the Ethereum blockchain, however the cryptographic primitive for this project are really outdated and I don't know enough about cryptography to update them. Can anyone help me to rewrite the code? The repo is here -> [https://github.com/kCox96/smart-contracts/blob/master/contracts/Secp256k1_noconflict.sol]
Please don't write your own crypto!
If you just want to verify ecdsa-signatures you can use ecrecover() a builtin function to verify signatures, or this library https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/cryptography/ECDSA.sol
If you really need these curve functions there are some libraries out there (e.g. https://github.com/tdrerup/elliptic-curve-solidity) but they also seem to be not well maintained
I understand dependency inversion when working inside a single module, but I would like to also apply it when I have a cross-module dependency. In the following diagrams I have an existing application and I need to implement some new requirements for reference data services. I thought I will create a new jar (potentially a stand-alone service in the future). The first figure shows the normal way I have approached such things in the past. The referencedataservices jar has an interface which the app will use to invoke it.
The second figure shows my attempt to use DIP, the app now owns its abstraction so it is not subject to change just because the reference data service changes. This seems to be a wrong design though, because it creates a circular dependency. MyApp depends on referencedataservices jar, and referencedataservices jar depends on MyApp.
So the third figure gets back to the more normal dependency by creating an extra layer of abstraction. Am I right? Or is this really not what DIP was intended for? Interested in hearing about other approaches or advice.
,
The second example is on the right track by separating the implementation from its abstraction. To achieve modularity, a concrete class should not be in the same package (module) as its abstract interface.
The fault in the second example is that the client owns the abstraction, while the service owns the implementation. These two roles must be reversed: services own interfaces; clients own implementations. In this way, the service presents a contract (API) for the client to implement. The service guarantees interaction with any client that adheres to its API. In terms of dependency inversion, the client injects a dependency into the service.
Kirk K. is something of an authority on modularity in Java. He had a blog that eventually turned into a book on the subject. His blog seems to be missing at the moment, but I was able to find it in the Wayback Machine. I think you would be particularly interested in the four-part series titled Applied Modularity. In terms of other approaches or alternatives to DIP, take a look at Fun With Modules, which covers three of them.
In second approach that you presented, if you move RefDataSvc abstraction to separate package you break the cycle and referencedataservices package use only package with RefDataSvc abstraction.
Other code apart from Composition Root in MyApp package should depend also on RefDataSvc. In Composition Root of your application you should then compose all dependencies that are needed in your app.
Here is a problem I've struggled with ever since I first started learning object-oriented programming: how should one implement a logger in "proper" OOP code?
By this, I mean an object that has a method that we want every other object in the code to be able to access; this method would output to console/file/whatever, which we would use for logging--hence, this object would be the logger object.
We don't want to establish the logger object as a global variable, because global variables are bad, right? But we also don't want to have the pass the logger object in the parameters of every single method we call in every single object.
In college, when I brought this up to the professor, he couldn't actually give me an answer. I realize that there are actually packages (for say, Java) that might implement this functionality. What I am ultimately looking for, though, is the knowledge of how to properly and in the OOP way implement this myself.
You do want to establish the logger as a global variable, because global variables are not bad. At least, they aren't inherently bad. A logger is a great example of the proper use of a globally accessible object. Read about the Singleton design pattern if you want more information.
There are some very well thought out solutions. Some involve bypassing OO and using another mechanism (AOP).
Logging doesn't really lend itself too well to OO (which is okay, not everything does). If you have to implement it yourself, I suggest just instantiating "Log" at the top of each class:
private final log=new Log(this);
and all your logging calls are then trivial: log.print("Hey");
Which makes it much easier to use than a singleton.
Have your logger figure out what class you are passing in and use that to annotate the log. Since you then have an instance of log, you can then do things like:
log.addTag("Bill");
And log can add the tag bill to each entry so that you can implement better filtering for your display.
log4j and chainsaw are a perfect out of the box solution though--if you aren't just being academic, use those.
A globally accessible logger is a pain for testing. If you need a "centralized" logging facility create it on program startup and inject it into the classes/methods that need logging.
How do you test methods that use something like this:
public class MyLogger
{
public static void Log(String Message) {}
}
How do you replace it with a mock?
Better:
public interface ILog
{
void Log(String message);
}
public class MyLog : ILog
{
public void Log(String message) {}
}
I've always used the Singleton pattern to implement a logging object.
You could look at the Singleton pattern.
Create the logger as a singleton class and then access it using a static method.
I think you should use AOP (aspect-oriented programming) for this, rather than OOP.
In practice a singleton / global method works fine, in my opinion. Preferably the global thing is just a framework to which you can connect different listeners (observer pattern), e.g. one for console output, one for database output, one for Windows EventLog output, etc.
Beware for overdesign though, I find that in practice a single class with just global methods can work quite nicely.
Or you could use the infrastructure the particular framework you work in offers.
The Enterprise Library Logging Application Block that comes from Microsoft's Pattern & Practices group is a great example of implementing a logging framework in an OOP environment. They have some great documentation on how they have implemented their logging application block and all the source code is available for your own review or modification.
There are other similar implementations: log4net, log4j, log4cxx
They way they have implemented the Enterprise Library Logging Application Block is to have a static Logger class with a number of different methods that actually perform the log operation. If you were looking at patterns this would probably be one of the better uses of the Singleton pattern.
I am all for AOP together with log4*. This really helped us.
Google gave me this article for instance. You can try to search more on that subject.
(IMHO) how 'logging' happens isn't part of your solution design, it's more part of whatever environment you happen to be running in - like System and Calendar in Java.
Your 'good' solution is one that is as loosely coupled to any particular logging implementation as possible so think interfaces. I'd check out the trail here for an example of how Sun tackled it as they probably came up with a pretty good design and laid it all out for you to learn from!
use a static class, it has the least overhead and is accessible from all project types within a simple assembly reference
note that a Singleton is equivalent, but involves unnecessary allocation
if you are using multiple app domains, beware that you may need a proxy object to access the static class from domains other than the main one
also if you have multiple threads you may need to lock around the logging functions to avoid interlacing the output
IMHO logging alone is insufficient, that's why I wrote CALM
good luck!
Maybe inserting Logging in a transparent way would rather belong in the Aspect Oriented Programming idiom. But we're talking OO design here...
The Singleton pattern may be the most useful, in my opinion: you can access the Logging service from any context through a public, static method of a LoggingService class.
Though this may seem a lot like a global variable, it is not: it's properly encapsulated within the singleton class, and not everyone has access to it. This enables you to change the way logging is handled even at runtime, but protects the working of the logging from 'vilain' code.
In the system I work on, we create a number of Logging 'singletons', in order to be able to distinguish messages from different subsystems. These can be switched on/off at runtime, filters can be defined, writing to file is possible... you name it.
I've solved this in the past by adding an instance of a logging class to the base class(es) (or interface, if the language supports that) for the classes that need to access logging. When you log something, the logger looks at the current call stack and determines the invoking code from that, setting the proper metadata about the logging statement (source method, line of code if available, class that logged, etc.) This way a minimal number of classes have loggers, and the loggers don't need to be specifically configured with the metadata that can be determined automatically.
This does add considerable overhead, so it is not necessarily a wise choice for production logging, but aspects of the logger can be disabled conditionally if you design it in such a way.
Realistically, I use commons-logging most of the time (I do a lot of work in java), but there are aspects of the design I described above that I find beneficial. The benefits of having a robust logging system that someone else has already spent significant time debugging has outweighed the need for what could be considered a cleaner design (that's obviously subjective, especially given the lack of detail in this post).
I have had issues with static loggers causing permgen memory issues (at least, I think that's what the problem is), so I'll probably be revisiting loggers soon.
To avoid global variables, I propose to create a global REGISTRY and register your globals there.
For logging, I prefer to provide a singleton class or a class which provides some static methods for logging.
Actually, I'd use one of the existing logging frameworks.
One other possible solution is to have a Log class which encapsulates the logging/stored procedure. That way you can just instantiate a new Log(); whenever you need it without having to use a singleton.
This is my preferred solution, because the only dependency you need to inject is the database if you're logging via database. If you're using files potentially you don't need to inject any dependencies. You can also entirely avoid a global or static logging class/function.