Can call static method with null reference

monarch_dodra monarchdodra at gmail.com
Sat Jun 22 10:11:09 PDT 2013


On Saturday, 22 June 2013 at 16:44:36 UTC, H. S. Teoh wrote:
> On Sat, Jun 22, 2013 at 06:34:25PM +0200, Namespace wrote:
>> >but that's a problem caused by the fact that static functions 
>> >can be
>> >called via an instance, and fixing that would mean making it 
>> >illegal
>> >to call static functions on instances (which I would love to 
>> >have
>> >happen but don't expect to ever happen).
>> >
>> >- Jonathan M Davis
>> 
>> What was the reason for this terrible design decision?
>
> I've asked about that, but never got a real answer. I'm still 
> hoping
> people would change their mind and reverse this bad decision. 
> Conflating
> static members with non-static members is just a really bad 
> idea.

I don't see what's so terrible about it: If A can do it, I don't 
see what an instance of a couldn't? I find that it is in line 
with what ufcs does: It streamlines the calling convention. This 
is particularly relevent to the fact that D has a lot of emphasis 
on "auto" type, which means that more often than not, it is easy 
to manipulate the instance, but more laborious to get the type.

EG: auto myObject = foo!"mode".getObject();
auto copy = myObject[0].bar.CreateInstance();

There! I wouldn't want to have to insert a typeof in there. My 
bar member is perfectly capable of creating and instance, so I 
don't see why I'd have to explicitly request this from the typeof.

... unless typeof could be used ufcs style, as a property, just 
like stringof et al. ... *THEN* we'd be talking.

I *HATE* writing "typeof(a).stringof" or whatever when everything 
screams at me to write "a.typeof.stringof". >:(


More information about the Digitalmars-d-learn mailing list