foobar wrote:
> FiL's scheme looks backwards to me. One of the main drawbacks
> of factories is the fact that they have non-standard names.
> Given a class Foo, How would I know to call a factory newFoo?
Well you'd know to call constructor functions because their name
implies they construct an object: new(), load(), from(T), etc.. I
_hate_ global functions like in my newFoo() example. I was simply
using it as an example of where factories hide information about
what's being returned in today's code. Constructor functions in
my proposal must always be attached to a type, and can't be
global, but their names are arbitrary (which is good for overload
distinction, like I've explained before).
> class LimitedAccount : Account {
> // "regular allocation" - on GC heap
> private Account new(Person p) {
> return GC.allocate!LimitedAccount(P);
> }
> // init
> this(Person p) {...}
> ...more code...
> }
>
> class Bank {
> Account new(Person p, AccountType t) {
> switch(t) {
> case AccountType.LIMITED: return LimitedAccount.new(p);
> ... more cases...
> }
> }
> }
>
> // usage:
> Account acc = Bank.new(PoorShmoe, AccountType.LIMITED);
This is pretty much exactly what I am advocating except I think
the allocator and c-tor can be combined (with a attribute
override), since the allocator is implicit half the time. I gave
an example in my original post:
class Foo {
this new() {
// Implicitly allocates Foo.
}
this new() @noalloc {
// Allocation must be explicit
// but must return type Foo.
}
static auto new() {
// Regular factory function.
// Allocate and return at will.
}
}