Is there any way to create any child contracts from a contract, example when someone call "createChildContract()" function. In solidity, simply using new operator sold the problem, how about vyper? Many thanks !
This solved my question:
create_forwarder_to()
Example at Uniswap's contract factory
Related
I have contract, which use another contract, which receives a pair of tokens, and returns the best price by comparing several exchanges.
Problem is if such tokens pair is not on the contract exchanges list, the contract returns an error.
I need just something like this for solidity 0.4.24, for a view function (not send)
try{
// get return from contract A
}catch{
// get return from contract B
}
I found solution with abi.encodeWithSelector()
I have a question about IOC, factories, and the Open/Closed principle.
consider, if you will, the following factory
public function PODocument( _type as string) as IPODocument
dim d as new PODocument
if _type = "service" then
d.header = new ServicePOHeader()
d.details = new ServicePOLineItems()
else if _type = "merchandise" then
d.header = new MerchandisePOHeader()
d.details = new MerchandisePOLineItems()
end if
return d
end function
This is working for me and I can nicely have a webpage show information about heterogeneous collections.
My challenge is that today someone told me sometimes a certain customer will order a service and merchandise together. Come on, who among us could have seen that coming?
So I write a new set of providers that handle the added complexity, changed the factory to include a case for the new type, I'm back off and running.
However, I have violated the open/closed principle by changing the factory, which was released to production.
Is there a way to set this up so that I am not constantly changing the factory?
thanks in advance.
Yes. The simplest example for your case would be to define a factory class for each _type, and name them ServiceFactory, MerchandiseFactory, etc, or put a <PODocumentType("Service")> etc on them.
Then just find all factories (for example, using reflection), put them in a Dictionary(Of String, IPODocumentFactory) and select correct one based on key.
In a more complicated case, IPODocumentFactory interface may include CanCreate() method in addition to Create(). Then you can select a factory on the list based on its opinion about current situation.
Note that the discovery and list resolution support is often provided out of the box by DI frameworks such as Unity or Autofac.
Here is the Method signature in the WCF service:
APIMessageList<APISimpleContact> GetMembers(string apiKey, APIContactSearchFilter filter);
APIMessageList inherits from IList. Once I have built a proxy against this WCF service the class name is APIMessageListOfAPISimpleContactjHldnYZV.
Why do I not get: APIMessageListOfAPISimpleContact?
It adds random text to the end of every APIMessageList object in the interface (there are several) They all end with the same few chars - jHldnYZV. I have looked online for possible causes, but I can't find any posts of people having this problem.
This is a purely cosmetic issue but this interface is exposed to our external customers so its appearance is important.
Anybody know why I am getting this problem?
Many thanks
Joe
Your solution will be at http://msdn.microsoft.com/en-us/library/ms731045.aspx. Basically, since you could have multiple "SimpleContract" classes (in different namespaces), WCF will add a disambiguation hash to the end of the contract name, which is what you have in the 8 chars at the end of the contract name. But you can control that, by using the CollectionDataContract and its Name property:
[CollectionDataContract(Name = "APIMessageListOfSimpleContract")]
public class APIMessageList : IList<SimpleContract> { ... }
We had a similar problem while using Generic types for return values. If we are not specifying a concrete type, the default data contract serializer or the WCF serializer is unable to infer the exact type of the returned entity. Hence it generates a random class name for the returned type.
In our project we overcame this problem by building a data contract which was of specific type and returned the same as a result of a WCF operation call.
My guess is that you are using a generic type and the serializer is unable to infer the type of the returned object.
I suggest you create a Data Transfer Object (DTO) and return the same from the WCF service. That should solve your problem.
Is it possible to configure Hiberate/NHibernate not to use the default constructor to create objects when reading from the database?
When Hibernate reads 10 customers from a table, it creates 10 Customer objects. It does this by
Customer c = new Customer();
Can I tell Hibernate to do the following instead:
Customer c = ACertainStaticFactory.CreateNewCustomer();
or even to manage a factory instance:
ACertainFactory factory = .....;
Customer c = factory.CreateNewCustomer();
or even more sophisticated, to pass a parameter which I set before:
// My client code
Query query = session.CreateQuery(...);
// either:
query.SetSomeParameter(someObject);
// or:
session.SetSomeParameter(someObject);
query.List();
// Hibernate should then behave like this:
Customer c = new Customer(someObject);
// or
Customer c = ACertainStaticFactory.CreateNewCustomer(someObject);
// etc.
Is that possible in anyway? If yes: How? If no: Is there an alternative?
When Hibernate reads 10 customers from a table, it creates 10 Customer objects. It does this by (...)
More precisely, Hibernate uses Class<T>#newInstance() to create new instances of an entity, which relies on the no-arg constructor. Hence the need to provide it.
Is that possible in anyway? If yes: How? If no: Is there an alternative?
Your requirement looks close to the Possible to have Hibernate hydrate objects with Factory? thread on Hibernate's forums so I'll quote Steve's answer (updated to match current names):
This is totally doable. In fact you
have two options:
create a custom EntityPersister implementation;
create a custom Interceptor implementation, specifically the
Interceptor.instantiate() method will
be of interest to you...
I think I'd go the interceptor way (not sure about your complex scenario but implementing the factory approach looks pretty easy).
Check this out, may be helpful:
http://fabiomaulo.blogspot.com/2008/11/entities-behavior-injection.html
I have a class called PriceStep. I keep a list of PriceStep objects in a class called PriceStepSearchSpace. Now I am required to have different PriceStepSearchSpace objects for different products and I need to keep them in some sort of a dictionary. I called this new class PriceStepSearchSpaceRepository.
Can you think of a simpler/shorter name?
You could call it Repository and put it in a namespace called PriceSteps.Searchspaces.
I might call it PriceStepSearchSpaces if it was unlikely that I would have any other type of collection of those objects. Otherwise, I like Timwi's idea of putting related classes into a namespace to prevent duplication of prefixes.
I would go with SearchSpace for your first and SearchSpaceDictionary for the second.
There's no need to preface a parent class with it's child class name!
However, you may want to re-think your object model, it's hard to give advice about that based on the info you provided.
PriceStep. PriceSteps. PriceStepsByProduct.