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