class extensions

[Bill Baxter]

kris wrote:
> Michael Deardeuff wrote:
>> Robert Fraser Wrote:
> [snip]
>>> I proposed this a while ago, and I agree this would be a good idea. 
>>> However, the more I think about it, the more I realize that in a 
>>> native-compiled language we're talking vtable problems - how do we 
>>> know when the vtable is finished? If partials are cross-module, it 
>>> would require recompilation of every involved module, and just be 
>>> generally problematic.
>>
>> Excellent point. Blast.
>> I think it still _is_ a good idea if you scrap the inheritance/vtable 
>> problem and only allow extension classes to use the syntax "a.foo(...);"
>> I guess what I'm getting at is, I don't like the prospect of working 
>> with code that in one line is "foo(a, ...);" and the next 
>> "a.foo(...);" With the extension class bit it makes it clear that only 
>> methods meant as a class extension can (and must) use the "a.foo();" 
>> syntax, which I prefer.
>> And, of course,  I'm in here for myself. j/k. But not really.
>>
>> --Michael Deardeuff
> 
> Yeah, the proposed extensions raised all kinds of red flags for me at 
> the conference.
> 
> Bluntly, it felt like the notion of "structured programming" was being 
> tossed out in favor of "slapdash programming" ... a brand new paradigm 
> to go along with the other(s) being adopted :)

It's pretty much the same deal as with property syntax.  A lot of folks 
think the use of property syntax with a function should need to be 
enabled explicilty to avoid nonsense like writefln = 5;

But Walter seems to think it's ok the way it is.  Given that, I can 
definitely see how he'd think making a.foo uniformly interchangable with 
foo(a) makes sense.  I guess with property syntax and this combined 
we'll have
    "a.value" == "value(a)" == "value = a"

Which seems pretty weird to me.

--bb