> I can tell you from experiments in the Twisted community that this kind of > "async object creation" without an explicit factory function is basically an > antipattern, for the following reasons: > More broadly, having constructors do I/O is an anti-pattern for these same > reasons; you just notice it faster in an async framework :). > -glyph
Thank you for sharing experience. However, anti-pattern is exactly what I'm doing. My experience is that whenever you try to push a concept into a predetermined pattern, overhead and maintenance costs mostly surpass the cost of developing the concept itself. This is a major distraction. The only patterns/frameworks to closely watch are the ones which are embedded in the problem domain. And the language should be able to address them without any "indirection". I found async style suprisingly fruitful in this area. If a concept of creation is inherently async, let it be that way without any intermediateries. Regards, Imran
