_Why does the sun go on shining?

I am not a fan of Ruby programming - not because I don't like it but because I have never used it nor do I even know how it looks like.

It is now apparent to me that someone prominent in the Ruby world had abruptly ended _his (or _her) on-line existence about ten months ago. The entity about whom I am discussing signs _himself (or _herself) off as _Why. Last August, all of _his/_her on-line presence were abruptly terminated.

The person that availed himself as _Why in Ruby conferences looked rather like Jack Black, doesn't he? Was Jack Black or a relative of Jack Black's hired to appear as _Why? _Was _Why a time-travelling renegade and could it be that when the relevant time-enforcement agency finally caught up with _Why, they abruptly closed all _his/_her _time infractions?

Anyway ... anyway is my favourite mood-changing word. If anyone reads my earlier post, you might read that I despise the word basically, because the word basically is basically used by people to reflect a change in the mood of conversation. Therefore, I urge people who are fond of using the word basically to transform their speech to using the word anyway, which should more accurately reflect any intent in changing the mood of a conversation. Basically, I cringe being near someone who prepends their phrases with the word basically.

Anyway, being rather unaware of _who _Why _is, or if _he/_she and _his/_her existence and subsequent abrupt disappearance are inventions of Rubyists to desperately call to attention their languishing language, I had scarce intentions to discuss _Why and _Ruby. My apologies to avid Rubyists, but I know that I do not know if Ruby is languishing - it is merely a component of the theory that Rubyists invented _Why.

This is about words that are subtly similar but are poles apart.

Was _Why's presence suddenly terminated or abruptly terminated? An event can be abrupt but not sudden, and the converse is true.

One could plan the abrupt end of a process without being sudden:

We had been planning for months to abruptly end the existence of _Why.

One could experience the suddenness of a non-abrupt event:

_Who was suddenly aware that _she had gradually fallen in love with _Why.

Another pair of words that provokes my displeasure is spontaneous vs automatic. Sometimes (or even frequently), you might encounter a sentence like

When the limousine stopped at the foyer, the concierge automatically rose to open the door for the VIP.

A concierge, any concierge, would beg to offer a more accurate opinion that a concierge is always spontaneous but never automatic! To be spontaneous is human, to be automatic is a machine.

I was boarding a bus in another country and I noticed notices printed beside both the front and back doors of the bus, which said, when translated to English,

Caution: automatic door.

But, but, ... those were remote-controlled doors. The driver had to spontaneously press a button to open or close either door.

Which is preferable: to be precise or be accurate? I remember a Physics professor in Engineering school striving to remind us

Engineering is a science in precision, not accuracy.  My dead grandfather clock is abruptly accurate twice a day, but it will never be precise.

What about the word remember? More often than not, the gerund remembering is used in place of recall. Remember is to place into memory or have in memory. Whereas, recall is to withdraw from memory.

The sentence

I am not remembering if _Why existed or is a mere fragment of my imagination.

means that the speaker intends not to place into memory any present awareness of _Why's existence. Perhaps, the speaker actually meant to say,

I cannot recall if _Why existed or is a mere fragment of my imagination.
(I am unable to withdraw from memory ...)

or, to say,

I do not remember if _Why existed or is a mere fragment of my imagination.
(I do not have in possession in my memory ...)

Is it logical to over-ride static members?

The Java language (or C#) does not allow static members of a class to be over-ridden. But what if there is a language that does?

Let us say that there is a class written in a hypothetical Java-like language

class DataSource{

  DataSource(Data data){
    this.data = data;
  }

  @override
  static Data getData(){
    return createFormData();
  }
  
  static <T extends Datasource> create(){
    Data data = getData();
    DataSource ds = new DataSource(data);
  }
}

Let us pretend that this language allows static members to be overridden

class GridDataSource
extends DataSource{
  GridDataSource(Data data){
    super(data);
  }

  @override
  static Data getData(){
    return createGridData();
  }
  
  static GridDataSource create(){
    Data data = getData();
    GridDataSource ds = new GridDataSource(data);
  }
}

You want a static method because you want it to be callable without instantiating the class, but you also want any derivative class to be expected to provide the method getData() as well as the factory method create(). For certain derivative classes you wish to over-ride getData() and for others you don't. Therefore, you need to consistently expect the method getData() to be present.

A so-called "OO purist" might say - this is not OO, redesign your algorithm to fit into OO constraints.

Forgive me a million times to be on the offensive - but first of all, who gets to be anointed an "OO purist" and secondly with what authority would such an anointed Chosen One pronounce that this isn't OO other than the few academic papers might have been read?

There should be absolutely nothing wrong with a programmer's preference as long as it is maintainable and extensible with the least of efforts. If a programmer finds this style of programming eases maintenance and extensibility - so be it. So, no debate about if this style of programming is good or bad.

The question to be answered is - is this logical or topologically sound?

At first purview, we could say that this is illogical.

1. Since the addressability of static members depend on the extension of the class, why don't you just make them class members rather than static members?
   Wrong answer - the factory method has to be static and, therefore, any method it calls has to be static.
2. The actual implemented class is not known until a class is instantiated.
   Wrong answer - that is due to the constraints of language's run-time architecture.
3. We would have to implement virtual references in the language and that would defeat the purpose of efficiency of having static members.
   Wrong answer - the run-time efficiency of static members is a side effect/benefit. The main reason for having static members is to be able to address those members without class instantiation.
4. Having virtual references designed to treat such a feature at run-time decreases run-time efficiency.
   Should the definition of OOP be constrained by the architecture of CPUs rather than linguistic topology? Why, processor makers could pander to virtualization, executable bit, etc and surely they could accommodate a little bit more? However, doesn't C# already have delegates? What about the planned implementation of closures in Java?

Such a feature is easily implemented with C# delegates, which would answer whether it is topologically possible to implement over-rideable static members. End of dispute.

class DataSource{

  delegate Data GetData();
  GetData getDataFuncton;

  // "static constructor" is run when class is loaded
  static DataSource(){
    getDataFuncton = new GetData(getData);
  }

  DataSource(Data data){
    this.data = data;
  }

  static Data getData(){
    return createFormData();
  }
  
  static <T extends Datasource> create(){
    Data data = getDataFuncton();
    DataSource ds = new DataSource(data);
  }
}

With this question settled, there should not be any more excuse not to allow contracting static members in an interface.